Peter Dimov <pdimov@gmail.com> wrote:

Ben Hutchings wrote: <snip>

...

I feel the naming of functions may give a false sense of generality and encapsulation when they actually only work in the way they are being used currently.

I'm not sure which functions do you have in mind here.

I'm perhaps overstating the case, but still: Firstly, atomic_read. I think people generally expect atomicity and ordering to go hand-in-hand - though I realise they don't have to - and the other functions whose names begin with "atomic_" do prevent reordering of their memory accesses, so this name could be misleading. Secondly, use_count's return values can only be used in very specific ways (e.g. the comparison with 0 as an optimisation in weak_ptr<>::lock). I realise that the use_count functions in shared_ptr and weak_ptr are documented as "only for debugging and testing purposes", but I was kind of thinking the name ought to suggest that. (Also the documentation fails to point out that return values can immediately become incorrect in multithreading systems, and has postconditions based on use_count() that won't necessarily be true if tested in real code, though this perhaps ought to be obvious.)

http://66.102.9.104/search?q=cache:1ZQ1uXtFUEIJ:www.pdimov.com/cpp/ shared_count_x86_exp2.hpp

Thanks for that.