You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Brian Geffon <br...@gmail.com> on 2014/10/04 06:03:47 UTC

C++ API shared_ptr dependecy

Hey all,
So there is a weird situation we're in with the c++ api where it has a
dependency on shared_ptr which can exist in memory or tr1/memory and
similarly in the namespace std:: and std;:tr1::, so in the cppapi's
shared_ptr.h file we have the following mess:
#include "ink_autoconf.h"


#if HAVE_STD_SHARED_PTR

#  include <memory>
#else

#  include <tr1/memory>

#endif


namespace atscppapi {

#if HAVE_STD_SHARED_PTR

  using std::shared_ptr;

#else

  using std::tr1::shared_ptr;

#endif


} /* atscppapi */

Re: C++ API shared_ptr dependecy

Posted by James Peach <jp...@apache.org>.
On Oct 6, 2014, at 10:56 AM, Brian Geffon <br...@gmail.com> wrote:

> James, I think the problem of requiring std::shared_ptr is that it wont
> work with some older compilers without adding --std=c++0x, such as g++ 4.4.x

In that case, I think you should check for what you need at build time and puke if it is not there.

> 
> Brian
> 
> On Mon, Oct 6, 2014 at 8:21 AM, James Peach <jp...@apache.org> wrote:
> 
>> On Oct 3, 2014, at 9:06 PM, Brian Geffon <br...@gmail.com> wrote:
>> 
>>> Hey all,
>>> So there is a weird situation we're in with the c++ api where it has a
>>> dependency on shared_ptr which can exist in memory or tr1/memory and
>> 
>> Just stop doing this. tr1 is ancient, so require std::shared_ptr in order
>> to build the C++ API. Then there's no possibility of confusion and this
>> problem goes away.
>> 
>>> similarly in the namespace std:: and std;:tr1::, so in the c++ api's
>>> shared_ptr.h file we have the following mess:
>>> 
>>> 
>>> #include "ink_autoconf.h"
>>> #if HAVE_STD_SHARED_PTR
>>> #  include <memory>
>>> #else
>>> #  include <tr1/memory>
>>> #endif
>>> 
>>> namespace atscppapi {
>>> #if HAVE_STD_SHARED_PTR
>>> using std::shared_ptr;
>>> #else
>>> using std::tr1::shared_ptr;
>>> #endif
>>> }
>>> 
>>> And we're including ink_autoconf.h only because it determines which
>>> implementation of shared_ptr the user has. This can't work because this
>>> file is installed and ink_autoconf.h no longer exists. amc, suggested the
>>> following trick to handle the namespacing but it still falls short when
>>> determining which file to include, does anyone have ideas of how we can
>>> remove this dependency on ink_autoconf.h?
>>> 
>>> namespace tr1 { }
>>> namespace std_tr1 {
>>> using namespace std;
>>> using namespace tr1;
>>> }
>>> 
>>> namespace atscppapi {
>>> using std_tr1::shared_ptr;
>>> }
>>> 
>>> 
>>> Brian
>>> 
>>> On Fri, Oct 3, 2014 at 9:03 PM, Brian Geffon <br...@gmail.com>
>> wrote:
>>> 
>>>> Hey all,
>>>> So there is a weird situation we're in with the c++ api where it has a
>>>> dependency on shared_ptr which can exist in memory or tr1/memory and
>>>> similarly in the namespace std:: and std;:tr1::, so in the cppapi's
>>>> shared_ptr.h file we have the following mess:
>>>> #include "ink_autoconf.h"
>>>> 
>>>> 
>>>> #if HAVE_STD_SHARED_PTR
>>>> 
>>>> #  include <memory>
>>>> #else
>>>> 
>>>> #  include <tr1/memory>
>>>> 
>>>> #endif
>>>> 
>>>> 
>>>> namespace atscppapi {
>>>> 
>>>> #if HAVE_STD_SHARED_PTR
>>>> 
>>>> using std::shared_ptr;
>>>> 
>>>> #else
>>>> 
>>>> using std::tr1::shared_ptr;
>>>> 
>>>> #endif
>>>> 
>>>> 
>>>> } /* atscppapi */
>>>> 
>> 
>> 


Re: C++ API shared_ptr dependecy

Posted by Brian Geffon <br...@gmail.com>.
James, I think the problem of requiring std::shared_ptr is that it wont
work with some older compilers without adding --std=c++0x, such as g++ 4.4.x

Brian

On Mon, Oct 6, 2014 at 8:21 AM, James Peach <jp...@apache.org> wrote:

> On Oct 3, 2014, at 9:06 PM, Brian Geffon <br...@gmail.com> wrote:
>
> > Hey all,
> > So there is a weird situation we're in with the c++ api where it has a
> > dependency on shared_ptr which can exist in memory or tr1/memory and
>
> Just stop doing this. tr1 is ancient, so require std::shared_ptr in order
> to build the C++ API. Then there's no possibility of confusion and this
> problem goes away.
>
> > similarly in the namespace std:: and std;:tr1::, so in the c++ api's
> > shared_ptr.h file we have the following mess:
> >
> >
> > #include "ink_autoconf.h"
> > #if HAVE_STD_SHARED_PTR
> > #  include <memory>
> > #else
> > #  include <tr1/memory>
> > #endif
> >
> > namespace atscppapi {
> > #if HAVE_STD_SHARED_PTR
> > using std::shared_ptr;
> > #else
> > using std::tr1::shared_ptr;
> > #endif
> > }
> >
> > And we're including ink_autoconf.h only because it determines which
> > implementation of shared_ptr the user has. This can't work because this
> > file is installed and ink_autoconf.h no longer exists. amc, suggested the
> > following trick to handle the namespacing but it still falls short when
> > determining which file to include, does anyone have ideas of how we can
> > remove this dependency on ink_autoconf.h?
> >
> > namespace tr1 { }
> > namespace std_tr1 {
> > using namespace std;
> > using namespace tr1;
> > }
> >
> > namespace atscppapi {
> > using std_tr1::shared_ptr;
> > }
> >
> >
> > Brian
> >
> > On Fri, Oct 3, 2014 at 9:03 PM, Brian Geffon <br...@gmail.com>
> wrote:
> >
> >> Hey all,
> >> So there is a weird situation we're in with the c++ api where it has a
> >> dependency on shared_ptr which can exist in memory or tr1/memory and
> >> similarly in the namespace std:: and std;:tr1::, so in the cppapi's
> >> shared_ptr.h file we have the following mess:
> >> #include "ink_autoconf.h"
> >>
> >>
> >> #if HAVE_STD_SHARED_PTR
> >>
> >> #  include <memory>
> >> #else
> >>
> >> #  include <tr1/memory>
> >>
> >> #endif
> >>
> >>
> >> namespace atscppapi {
> >>
> >> #if HAVE_STD_SHARED_PTR
> >>
> >> using std::shared_ptr;
> >>
> >> #else
> >>
> >> using std::tr1::shared_ptr;
> >>
> >> #endif
> >>
> >>
> >> } /* atscppapi */
> >>
>
>

Re: C++ API shared_ptr dependecy

Posted by James Peach <jp...@apache.org>.
On Oct 3, 2014, at 9:06 PM, Brian Geffon <br...@gmail.com> wrote:

> Hey all,
> So there is a weird situation we're in with the c++ api where it has a
> dependency on shared_ptr which can exist in memory or tr1/memory and

Just stop doing this. tr1 is ancient, so require std::shared_ptr in order to build the C++ API. Then there's no possibility of confusion and this problem goes away.

> similarly in the namespace std:: and std;:tr1::, so in the c++ api's
> shared_ptr.h file we have the following mess:
> 
> 
> #include "ink_autoconf.h"
> #if HAVE_STD_SHARED_PTR
> #  include <memory>
> #else
> #  include <tr1/memory>
> #endif
> 
> namespace atscppapi {
> #if HAVE_STD_SHARED_PTR
> using std::shared_ptr;
> #else
> using std::tr1::shared_ptr;
> #endif
> }
> 
> And we're including ink_autoconf.h only because it determines which
> implementation of shared_ptr the user has. This can't work because this
> file is installed and ink_autoconf.h no longer exists. amc, suggested the
> following trick to handle the namespacing but it still falls short when
> determining which file to include, does anyone have ideas of how we can
> remove this dependency on ink_autoconf.h?
> 
> namespace tr1 { }
> namespace std_tr1 {
> using namespace std;
> using namespace tr1;
> }
> 
> namespace atscppapi {
> using std_tr1::shared_ptr;
> }
> 
> 
> Brian
> 
> On Fri, Oct 3, 2014 at 9:03 PM, Brian Geffon <br...@gmail.com> wrote:
> 
>> Hey all,
>> So there is a weird situation we're in with the c++ api where it has a
>> dependency on shared_ptr which can exist in memory or tr1/memory and
>> similarly in the namespace std:: and std;:tr1::, so in the cppapi's
>> shared_ptr.h file we have the following mess:
>> #include "ink_autoconf.h"
>> 
>> 
>> #if HAVE_STD_SHARED_PTR
>> 
>> #  include <memory>
>> #else
>> 
>> #  include <tr1/memory>
>> 
>> #endif
>> 
>> 
>> namespace atscppapi {
>> 
>> #if HAVE_STD_SHARED_PTR
>> 
>> using std::shared_ptr;
>> 
>> #else
>> 
>> using std::tr1::shared_ptr;
>> 
>> #endif
>> 
>> 
>> } /* atscppapi */
>> 


Re: C++ API shared_ptr dependecy

Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Saturday, October 4, 2014, 10:57:27 AM, you wrote:

> Make one of your public include files autoconf generated? Like we do for the C APIs definitions file.

Close, but I think what would be better is to combine this with Brian's original thought.

So in Brian's shared pointer header, he has basically his original stuff -

#if ATS_USE_TR1
#  include <tr1/memory>
#else
#  include <memory>
#endif

namespace atscppapi {
#if ATS_USE_TR1
  using std::shared_ptr;
#else
  using std::tr1::shared_ptr;
#endif


what we do is use a variant of Leif's suggestion and make this a generated file. The original has something lke

# if ! defined(ATS_USE_TR1)
#   define ATS_USE_TR1 @TS_USE_TR1@
# endif

This way we get the configure time value as the default but if the plugin writer really wants control he can -D ATS_USE_TR1 to force a a different result. This could go in a common include or directly in the shared_ptr header. It depends on whether Brian thinks we will have more situations like this.


Re: C++ API shared_ptr dependecy

Posted by Leif Hedstrom <zw...@apache.org>.
Make one of your public include files autoconf generated? Like we do for the C APIs definitions file.

Just a thought.

-- Leif 



> On Oct 3, 2014, at 10:06 PM, Brian Geffon <br...@gmail.com> wrote:
> 
> Hey all,
> So there is a weird situation we're in with the c++ api where it has a
> dependency on shared_ptr which can exist in memory or tr1/memory and
> similarly in the namespace std:: and std;:tr1::, so in the c++ api's
> shared_ptr.h file we have the following mess:
> 
> 
> #include "ink_autoconf.h"
> #if HAVE_STD_SHARED_PTR
> #  include <memory>
> #else
> #  include <tr1/memory>
> #endif
> 
> namespace atscppapi {
> #if HAVE_STD_SHARED_PTR
>  using std::shared_ptr;
> #else
>  using std::tr1::shared_ptr;
> #endif
> }
> 
> And we're including ink_autoconf.h only because it determines which
> implementation of shared_ptr the user has. This can't work because this
> file is installed and ink_autoconf.h no longer exists. amc, suggested the
> following trick to handle the namespacing but it still falls short when
> determining which file to include, does anyone have ideas of how we can
> remove this dependency on ink_autoconf.h?
> 
> namespace tr1 { }
> namespace std_tr1 {
>  using namespace std;
>  using namespace tr1;
> }
> 
> namespace atscppapi {
>  using std_tr1::shared_ptr;
> }
> 
> 
> Brian
> 
>> On Fri, Oct 3, 2014 at 9:03 PM, Brian Geffon <br...@gmail.com> wrote:
>> 
>> Hey all,
>> So there is a weird situation we're in with the c++ api where it has a
>> dependency on shared_ptr which can exist in memory or tr1/memory and
>> similarly in the namespace std:: and std;:tr1::, so in the cppapi's
>> shared_ptr.h file we have the following mess:
>> #include "ink_autoconf.h"
>> 
>> 
>> #if HAVE_STD_SHARED_PTR
>> 
>> #  include <memory>
>> #else
>> 
>> #  include <tr1/memory>
>> 
>> #endif
>> 
>> 
>> namespace atscppapi {
>> 
>> #if HAVE_STD_SHARED_PTR
>> 
>>  using std::shared_ptr;
>> 
>> #else
>> 
>>  using std::tr1::shared_ptr;
>> 
>> #endif
>> 
>> 
>> } /* atscppapi */
>> 

Re: C++ API shared_ptr dependecy

Posted by Brian Geffon <br...@gmail.com>.
Hey all,
So there is a weird situation we're in with the c++ api where it has a
dependency on shared_ptr which can exist in memory or tr1/memory and
similarly in the namespace std:: and std;:tr1::, so in the c++ api's
shared_ptr.h file we have the following mess:


#include "ink_autoconf.h"
#if HAVE_STD_SHARED_PTR
#  include <memory>
#else
#  include <tr1/memory>
#endif

namespace atscppapi {
#if HAVE_STD_SHARED_PTR
  using std::shared_ptr;
#else
  using std::tr1::shared_ptr;
#endif
}

And we're including ink_autoconf.h only because it determines which
implementation of shared_ptr the user has. This can't work because this
file is installed and ink_autoconf.h no longer exists. amc, suggested the
following trick to handle the namespacing but it still falls short when
determining which file to include, does anyone have ideas of how we can
remove this dependency on ink_autoconf.h?

namespace tr1 { }
namespace std_tr1 {
  using namespace std;
  using namespace tr1;
}

namespace atscppapi {
  using std_tr1::shared_ptr;
}


Brian

On Fri, Oct 3, 2014 at 9:03 PM, Brian Geffon <br...@gmail.com> wrote:

> Hey all,
> So there is a weird situation we're in with the c++ api where it has a
> dependency on shared_ptr which can exist in memory or tr1/memory and
> similarly in the namespace std:: and std;:tr1::, so in the cppapi's
> shared_ptr.h file we have the following mess:
> #include "ink_autoconf.h"
>
>
> #if HAVE_STD_SHARED_PTR
>
> #  include <memory>
> #else
>
> #  include <tr1/memory>
>
> #endif
>
>
> namespace atscppapi {
>
> #if HAVE_STD_SHARED_PTR
>
>   using std::shared_ptr;
>
> #else
>
>   using std::tr1::shared_ptr;
>
> #endif
>
>
> } /* atscppapi */
>