shared_ptr 1.27 w/gcc 2.96 (VxWorks)

From: Brian (bneal_at_[hidden])
Date: 2003-03-04 20:00:49

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