boost::shared_ptr vs std::tr1::shared_ptr on multi os compilation - c++

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.

Answer 1

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.

Answer 2

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.