atomic_count default constructor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A couple of questions: Is there any rational behind the fact that boost::detail::atomic_count doesn't have a default constructor? For what reason is atomic_count an implementation detail, and not available for general use? (i.e. why is it in boost::detail, and not boost::) - -- Clark S. Cox III clarkcox3@gmail.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgxMRXkPInUR5a8wRApfMAJoCiK/xH7K0u2GZnn3QoEk42bqznwCfQ9r0 s60aQuCL2IC1CB1Xi5uhBqQ= =roHz -----END PGP SIGNATURE-----
Clark S. Cox III wrote:
A couple of questions:
Is there any rational behind the fact that boost::detail::atomic_count doesn't have a default constructor?
The interface is specified in a way that makes 'int' or 'long' meet its requirements, so that one can typedef atomic_count to int/long in ST builds.
For what reason is atomic_count an implementation detail, and not available for general use? (i.e. why is it in boost::detail, and not boost::)
It wasn't considered ready for public consumption. An atomic operations library is hard to get right, as both interface and implementation, which is why we still don't have one in Boost. I think that we've now reached a degree of understanding that will make it possible to specify and implement one. So we should have one by 1.36, maybe even 1.35 if we hurry up. :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Dimov wrote:
Clark S. Cox III wrote:
A couple of questions:
Is there any rational behind the fact that boost::detail::atomic_count doesn't have a default constructor?
The interface is specified in a way that makes 'int' or 'long' meet its requirements, so that one can typedef atomic_count to int/long in ST builds.
OK, that makes perfect sense, thanks. - -- Clark S. Cox III clarkcox3@gmail.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhEXYXkPInUR5a8wRAhzWAJ42WK68VclWFMkIGCcGuy+UF2nAlgCfTOUo 9ZTYvBOV4Qu8LWFTGt8VYK8= =1KDd -----END PGP SIGNATURE-----
participants (2)
-
Clark S. Cox III
-
Peter Dimov