views:

153

answers:

3

I am not yet a Boost user. I am however planning to go into it as soon as possible. However I am little concerned about Boost, and the likely future name collisions or differences with the forthcoming C++0x. (Maybe it is not a real issue, but for example I find the boost lambdas syntax pretty ugly, BOOST_FOREACH aggressive to the eye, and other only aesthetic personal views).

I am really interested by the TR2, which seems to be implemented by the libraries Boost.Thread and just::thread. Both seems to be written and maintained by Anthony Williams.

But just::thread claims to be closely compliant with the TR2.

I wanted to know if any one of you would indicate me to use one or the other. just::thread is not free, but if it was to be really just like TR2, I am tempted.

Any thought ?

+4  A: 

I think it's too early to say that a library is "just like TR2". The TR2 will be released after C++0x, which itself hasn't even been released yet.

However, the Boost.Thread library also claims to follow the development in the Standardization Commitee.

I would prefer any Boost library over its "original", because Boost is committed to high quality and the Boost community maintains libraries collaboratively, as opposed to a private lib that just happened to migrate to boost.

You don't have to be afraid of name clashes, since what is currently in the boost:: namespace will stay in the namespace, and all TR2 stuff will probably go to std::tr2::.

fat-lobyte
+1  A: 

At the present time I am experimenting, on Linux, with the boost, just::thread libraries and the so-called 'experimental' C++Ox features of the gcc g++ 4.5 compiler. With regard to threading I have up to press I have found the code that I have written for just::thread and the g++ compiler to be 100% compatible. The boost libraries (1.43) are markedly not compatible with the former two. However, for my production code I use the boost libraries.

Name collision should not be a problem with the correct and judicious use of the available namespaces in boost, just::thread and the g++ compilers. I have no problem using just::thread with the C++Ox g++ features; indeed it is recommended by just::thread that these features are used, such as variadic templates.

Sam
What do you mean by "boost libraries (1.43) are markedly not compatible with the former two". What kind of compatibility are you talking about ?
Stephane Rolland
@Stephane: 'code that I have written for just::thread and the g++ compiler to be 100% compatible'; code compatible in the sense that code written that compiles and links successfully for just::thread under C++Ox will compile and link successfully using only C++Ox g++ 4.5 without modification. I have not been able to achieve this compatibility with the boost libraries.
Sam
@thanx Sam. I am still hesitating, but this is a good point for just::thread.
Stephane Rolland
A: 

Best advise at this time - none of the above :-)

Unless you have an absolutely pressing need, you'll save yourself a lot of time and grief by just waiting till C++0x settles first, which is going to take about 2 yr. If someone is asking you to go chasing moving targets - ask to see the money first :-) and a big retainer :-))

Like in many other cases it's best to first ask yourself "what are my actual needs"? If it's learning multi-threading development, then spending time with C# or Java will be much easier on your nerves. If you need to start developeing a production level system, then you already know your target platform and the best you can do is to stick with whatever is a tried-by-fire lib for multi-threading on your target platform and has full debugger support. Just to repeat again - full debugger support and integration is what decides the quaility of you life in the thread land.

If you touch Boost, make sure you have enough time to ensure that it doesn't have dependencies on a dozen of other boost-something files and then another dozen ... unless you are afficionado that is :-) If you touch a libraty tht claims automatic dedlock detection be prepared to pay in CPU cycles and deal with potentially unwanted interference.

ZXX