We are using boost 1.27 (I know, I know) with the real-time operating system VxWorks, which ships with its own "special" version of gcc 2.96 (not that same as Red Hats - I know, I know). Today I finally got around to providing a version of atomic_count.hpp for VxWorks. I had to play some games with #defines to get BOOST_HAS_THREADS and all the other things set up right before my implementation would get chosen. Once that was squared away, I put a cout in the constructor of my atomic_count class just be sure it was all working. I then stamped down a shared_ptr<int> and much to my surprise: no text output. I traced it back to the constructor for counted_base_impl (a templated class). That constructor was being called, but it inherits from counted_base, and that constructor was just not getting called! I searched your bug list on source forge but found no mention of this. But then again, its not really a boost bug! I then took a look at boost 1.29 and noticed that lots of things had been reworked in this area, so now looks like the reason to start using 1.29. I'm afraid I am stuck with VxWorks and that compiler though... So I'm just throwing this out in case anyone is remotely in the same situation as we are. I will start using 1.29 and see what happens. Hopefully its not too hard to customize the OS specific part in 1.29. I also suggest a note get added to the shared_ptr documentation about this OS specific mutex stuff thats going on. I got curious about how that was done and decided to look. Had I not done this, my shared_ptr's reference count would not have been thread safe and I wouldn't have known this. Also, is there a "what has changed in this new version of boost" file somewhere? Thanks again everyone. BN