Boost.Thread and Boost.Move collision
Hi, I've recently received some bugs caused by name collision between Boost.Move and Boost.Thread. Like many other libraries, Boost.Thread has its own move emulation code, and those functions are in the top-level namespace. I guess there is no trivial solution for this. Options: 1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move I would like to know your opinion on this as this issue is related to two official Boost libraries. Best, Ion
1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move
FWIW, I think 3) is what sounds obvious to me. Now maybe there's reasons to avoid coupling those libraries together but I'm not sure what they would be. Philippe
On 01/12/11 11:34, Ion Gaztañaga wrote:
I've recently received some bugs caused by name collision between Boost.Move and Boost.Thread. Like many other libraries, Boost.Thread has its own move emulation code, and those functions are in the top-level namespace.
I guess there is no trivial solution for this. Options:
1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move
I would like to know your opinion on this as this issue is related to two official Boost libraries.
Boost.Thread should definitely use Boost.Move. That's always been the plan. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
El 01/12/2011 14:16, Anthony Williams escribió:
On 01/12/11 11:34, Ion Gaztañaga wrote:
I've recently received some bugs caused by name collision between Boost.Move and Boost.Thread. Like many other libraries, Boost.Thread has its own move emulation code, and those functions are in the top-level namespace.
I guess there is no trivial solution for this. Options:
1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move
I would like to know your opinion on this as this issue is related to two official Boost libraries.
Boost.Thread should definitely use Boost.Move. That's always been the plan.
Ok, I guess this won't be a trivial change, some let me know if I can help. Ion
On 12/01/2011 12:34 PM, Ion Gaztañaga wrote:
I guess there is no trivial solution for this. Options:
1) Move Boost.Move elements to boost::move:: namespace
I advise against this solution. It would break compatibility for Boost.Move users.
2) Move Boost.Thread elements to boost::thread namespace
That should be fine. Assuming the move emulation of boost thread is an implementation detail, this doesn't affect users at all.
3) Modify Boost.Thread to make use of Boost.Move
That would be good, but could take more time to do than 2).
Mathias Gaunard-2 wrote
On 12/01/2011 12:34 PM, Ion Gaztañaga wrote:
I guess there is no trivial solution for this. Options:
1) Move Boost.Move elements to boost::move:: namespace
I advise against this solution. It would break compatibility for Boost.Move users.
Boost.Thread was using boost::move since a long time as there was no thread namespace. When Boost.Move was introduced in Trunk, Boost.Thread should be adapted to use Boost.Move, but this was not done. Too late.
2) Move Boost.Thread elements to boost::thread namespace
That should be fine. Assuming the move emulation of boost thread is an implementation detail, this doesn't affect users at all.
The problem is that this is part of the interface and not an implementation detail. What I purpose for the short term (1.49) is to let the user to choose the namespace for the move function (by default Boost.Thread will use boost::), and the user could state that it should use boost::thread:: instead.
3) Modify Boost.Thread to make use of Boost.Move
That would be good, but could take more time to do than 2).
There are a lot of uses of move semantics in Boost.Thread and this will surely take some time. I don't know yet if it will be possible to provide both move semantic emulations at once without breaking the interface. I suspect that a version 2 for Boost.Thread seems necessary. Given the number of tickets related to move semantics, it seems that this last option is the long term option. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Thread-and-Boost-Move-collision-tp4... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 12/1/2011 6:34 AM, Ion Gaztañaga wrote:
Hi,
I've recently received some bugs caused by name collision between Boost.Move and Boost.Thread. Like many other libraries, Boost.Thread has its own move emulation code, and those functions are in the top-level namespace.
I guess there is no trivial solution for this. Options:
1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move
I would like to know your opinion on this as this issue is related to two official Boost libraries.
Without dealing with Boost.Move versus Boost.Thread I am always for libraries putting things into their own namespace if that does not negatively impact the usefulness of a library, and by "negatively impact" I do not mean the trivial extra typing of 'someNamespace::someElement' as opposed to just 'someElement'. An end-user can always change that via the 'using namespace someNamespace' or 'using someNamespace::someElement' when he desires. I am actually alarmed at the Boost libraries who put names into the boost top level namespace and see this as a very bad practice.
On 1 December 2011 17:05, Edward Diener <eldiener@tropicsoft.com> wrote:
An end-user can always change that via the 'using namespace someNamespace' or 'using someNamespace::someElement' when he desires.
Not strictly true, as you can't do it* when you are declaring something in a header. This makes things like Boost.Multiindex a bit unwieldy. *Well, technically you can do that in a header too, but most sane coding guidelines discourage it, for the same reasons we don't want everything in the top level boost namespace. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
An end-user can always change that via the 'using namespace someNamespace' or 'using someNamespace::someElement' when he desires.
Not strictly true, as you can't do it* when you are declaring something in a header. This makes things like Boost.Multiindex a bit unwieldy.
*Well, technically you can do that in a header too, but most sane coding guidelines discourage it, for the same reasons we don't want everything in the top level boost namespace.
It should be OK to do it in a header inside a detail namespace, right? Regards, Nate
participants (8)
-
Anthony Williams -
Edward Diener -
Ion Gaztañaga -
Mathias Gaunard -
Nathan Ridge -
Nevin Liber -
Philippe Vaucher -
Vicente Botet