boost::shared_ptr vs std::tr1::shared_ptr on multi os compilation

Question

I have maintained different code for browser plugin(c++) for windows and mac system. The difference of the code is only for shared pointer.
In windows version I am using std::tr1::shared_ptr and on Mac version am using boost::shared_ptr.

Now I wanted to merge these code into one.I wanted to use std::tr1::shared_ptr in both code and maintain single source code but two different solution/project folder. This browser plugin support up to OSX 10.5 onwards.Presently I am compiling in Xcode 4.6.2(Apple LLVM compiler).Basically I am Windows programmer and mostly work on Visual Studio.

My question is Will Mac Older version will support plugin with this change.Is this is a good idea ? Please let me know whether boost is useful in this case.

Jaffa · Answer 1 · 2013-06-11T12:43:20.093

First of all, boost::shared_ptr and std::tr1::shared_ptr are almost the same, but if you can you should use std::shared_ptr instead by enabling C++11 support (default on VS12 I think, to be enabled in clang / llvm).

The shared_ptr is a template class wrapping a pointer, thus the whole code is instanciated when you compile your program: the original class implementation resides in a header file which is incorporated in your translation unit (each separate file being built).

As such, you don't need any specific library to use shared_ptr (neither a .dll nor a .so or something else on Mac). So your program will run on any machine for which it has been built, you don't require additional library to run it.

You can also - for compatibility reason - use your own wrapper around the shared_ptr:

namespace my_code {
#if defined(_STD_TR1_SHARED_PTR)
    using std::tr1::shared_ptr;
#elif defined(_STD_SHARED_PTR)
    using std::shared_ptr;
#else
    using boost::shared_ptr;
#endif
}

Thus you can access my_code::shared_ptr which will resolve to the appropriate type depending on the macros you define. Note that this only works if you use a compatible interface for all those types, but this should be the case.

@Geoffroy... did you just copy my answer into the end of yours? Looks like I answered shortly before you, then you saw my answer and copied it completely into your own. Poor form. — Dennis, Jun 11 '13 at 13:29
@Dennis no I didn't copy but I agree there are some similarities. Btw I'm using `using` instead of `typedef`, which is IMO more elegant — Jaffa, Jun 11 '13 at 13:33
@Geoffroy - Hmmm, I'm not convinced. Why did you not include it as part of your original answer? `using` is a nice addition to C++, but for it to be elegant it must be used correctly, which is something that you have failed to do. — Dennis, Jun 11 '13 at 13:41

score 0 · Answer 2 · answered Jun 11 '13 at 12:36

Why don't you just test it? An easy first step would be to use a typedef to change the actual shared pointer definition under the hood:

namespace myNs{
    #ifdef _USE_STD_SRDPTR
    typedef std::shared_ptr sharedPtr;
    #else
    typedef boost::shared_ptr sharedPtr; //default to boost if no symbol defined
    #endif
}

//in code replace old shared pointer usage
myNs::sharedPtr<Fruit> ourFruit( new Banana(WONKY) );

This way you can replace it in both code libraries, and change the underlying implementation whenever you want. You can add support for more options (e.g. the tr1 version) as you need to without changing your code. Of course all options need to have the same interface or the code won't compile.

boost::shared_ptr vs std::tr1::shared_ptr on multi os compilation

2 Answers2