Lightweight Mutex and others
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests. I think several of the modules should have a more permanent "home". Just from the names it seems that the following should be considered for promotion as thier utility goes beyond that of an impementation detail for any specific library. lightweight_mutex interlocked atomic_count binary_search ut8_codecvt_facet and it seems others should be part of particular libraries rather than boost/detail/ sp_* shared_? Robert Ramey
Robert Ramey wrote:
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests.
Speaking of lightweight_mutex, it was only intended as a stopgap measure until the 'real' boost::mutex becomes header-only and 'lightweight'. This should happen any day now. :-)
On Mon, 2007-05-28 at 20:27 +0300, Peter Dimov wrote:
Robert Ramey wrote:
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests.
Speaking of lightweight_mutex, it was only intended as a stopgap measure until the 'real' boost::mutex becomes header-only and 'lightweight'. This should happen any day now. :-)
I'm taking this to imply that the conversion is already occurring. Could the header-only-ness please be made an option? Thanks, Sohail
Sohail Somani wrote:
On Mon, 2007-05-28 at 20:27 +0300, Peter Dimov wrote:
Robert Ramey wrote:
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests.
Speaking of lightweight_mutex, it was only intended as a stopgap measure until the 'real' boost::mutex becomes header-only and 'lightweight'. This should happen any day now. :-)
I'm taking this to imply that the conversion is already occurring. Could the header-only-ness please be made an option?
I don't see how. What do you expect to gain from the optional header-only-ness?
On Mon, 2007-05-28 at 23:37 +0300, Peter Dimov wrote:
Sohail Somani wrote:
On Mon, 2007-05-28 at 20:27 +0300, Peter Dimov wrote:
Robert Ramey wrote:
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests.
Speaking of lightweight_mutex, it was only intended as a stopgap measure until the 'real' boost::mutex becomes header-only and 'lightweight'. This should happen any day now. :-)
I'm taking this to imply that the conversion is already occurring. Could the header-only-ness please be made an option?
I don't see how.
What do you expect to gain from the optional header-only-ness?
Hmm. Well not #include'ing <windows.h> is one. I don't mean to start this whole header-only thing again, *but* would be nice if it weren't forced. Thanks, Sohail
Sohail Somani wrote:
On Mon, 2007-05-28 at 23:37 +0300, Peter Dimov wrote:
Sohail Somani wrote:
On Mon, 2007-05-28 at 20:27 +0300, Peter Dimov wrote:
Robert Ramey wrote:
I'm looking at some code in boost/detail - in particular Lightweight mutex. Is there any chance that this as well as other useful modules can get promoted to boost "first class" status. That is would include thier own documentation(especially) and tests.
Speaking of lightweight_mutex, it was only intended as a stopgap measure until the 'real' boost::mutex becomes header-only and 'lightweight'. This should happen any day now. :-)
I'm taking this to imply that the conversion is already occurring. Could the header-only-ness please be made an option?
I don't see how.
What do you expect to gain from the optional header-only-ness?
Hmm. Well not #include'ing <windows.h> is one.
Neither lightweight_mutex.hpp nor a future header-only boost/mutex.hpp include (or will include) <windows.h>.
I don't mean to start this whole header-only thing again, *but* would be nice if it weren't forced.
I'm not sure that I understand your usage of 'forced'. The problem that motivated the creation of lightweight_mutex is that boost::mutex forces a dependency on the Boost.Threads library. This is unacceptable for many libraries, both header-only and otherwise. You can't solve that with making a boost::mutex that is optionally header-only, because it will probably lead to ODR violations when library A uses its header-only variant and program B uses both the out of line variant of boost::mutex and library A.
participants (3)
-
Peter Dimov -
Robert Ramey -
Sohail Somani