Ben,

Atomic operations are highly platform-dependent, with different platforms having different capabilities and many requiring use of assembly language rather than providing an API for atomic operations.

Would that be a problem? I have implemented this for our internal managed pointer class, and our code needs to run on a few different platforms (At the moment I am discussing the posibility of contributing to boost with our legal dept - note that it wasn't until recently that I was allowed to even post to an external mail group. Before that I used to follow boost quite closely)

Second, shared_ptr has two counters and updating them safely without using a lock requires some subtlety.

On ia32, ia64 and amd64 you can always use DCAS. On Ultrasparc you could restrict the counter to 32-bits and use CAS (64-bit). You can add other platforms as the implementation becomes available, but use a lock by default.

It's something I meant to implement but hadn't quite got round to. Perhaps I could make it work on g++ (and hence most Linux configurations) by using libstdc++'s atomic primitives? I

No. This is not portable enough. The problem is that libstdc++'s atomic ops come with libstdc++ which precludes you from using other standard library implementations. The ones that come with Linux in sys/atomic.h tend to be quite inconsistent, not to mention that many are implemented in such a way that they don't return the new/old value. On Solaris, sys/atomic.h ops are not available in user space anyway, not to mention that they are declared as extern - so they can't be inlined.

don't think they are really public though, so this might be a bad idea.

I think this would be a great idea, and it would make shared_ptr a lot more acceptable at our company. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.