________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Peter Dimov [pdimov@pdimov.com] Enviado el: viernes, 10 de abril de 2009 19:21 Para: boost@lists.boost.org Asunto: Re: [boost] atomic_count::operator++ return type JOAQUIN M. LOPEZ MUÑOZ:
Hi,
Some of the implementations of boost::detail::atomic_count::operator++ return a long (vg. Win32) while for others the return type is void. Is it feasible to change this so that a long (i.e. the value of the atomic count after incrementing) is returned always? As it happens, I have a usage case for this in Boost.Flyweight.
What memory visibility guarantees does your use case need? op++ returns no value because it currently promises no visibility guarantees.
I'm afraid I don't quite get what you mean exactly by memory visibility in this context: I guess I need the same behavior (mutatis mutandis) as given by op--. In case it sheds some light, the usage case I talk about can be taken a a look at https://svn.boost.org/trac/boost/browser/trunk/boost/flyweight/refcounted.hp... The protocol is a classical refcounting mechanism with a twist due to the possiblity that values are retrieved even if their recount drops to zero. There code's rationale is commented, but don't hesitate to ask if something's not clear. Of course I wouldn't need the extension to op++ if there's an alternative manner to implement the protocol . Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo