Faced a funny problem yesterday. I started changing the implementation of a class such that it uses shared_ptr<> wrapped dynamic object rather than obj*. Naturally, the right and sane thing to do to. However, the same class also needs to support serialization, implemented using the boost::serialization library. After all the dependent code were fixed for this change, I got a nasty error while compiling

c:\sdks\boost_1_45_0\boost\serialization\access.hpp(118) : error C2039: ’serialize’ : is not a member of ’std::tr1::shared_ptr<_Ty>’
with
[
_Ty=myclass
]
….

The …. is 475 lines long! Intimidating, to say the least.

Digging into serialization docs, it was evident that it supports shared_ptr<>. Research on the web also pointed to the same. I was puzzled. What could I be doing wrong? I was almost about to revert back to my non-shared_ptr<> implementation and then it hit me — shared_ptr<> is now part of STL as it’s been adopted as part of TR1 and I could be using std::shared_ptr<> instead of the one in the boost namespace. And boost::serialization implementation could only be supporting the boost version.

My intuition was right, I was indeed using the std::shared_ptr<> (actually I had declared it as std::tr1::shared_ptr<>, as VC places all TR1 extensions in a separate namespace). Redeclaring it to use boost::shared_ptr<> fixed the problem.

Moral of the story:

• Never be intimidated by template error messages.
• If you’re using esoteric boost libraries, stick to boost data types even if equivalent ones are available as part of the TR1 standardization