C++11 and Boost Library

The C++11 standard introduces a lot of things in the boost library, and for everyone, you can use C++11 instead of the previously used boost library.

But there are some things that need our attention.

Found a good article, source:
Https://meetingcpp.com/index.php/br/items/c11-and-boost.html

Some parts of the standard Library in c++11 is predated in boost. When playing around with c++11, you get used to using some parts in the standard Library that is used in c++03 with their Boost counterpart. Also, there is some libraries now occuring, which be c++11 based, so interfacing with either boost or c++11 code is soon an issue.

Boost have been used in c++03 for years, so it the natural choice to use Boost versions still in C++11 which is now PA RT of std::, in order to is able to interface with c++03. But also some people would be a happy to use c++11, and prefer the standard Library over using boost. And both positions is mixable to any extend, none is wrong. Still, getting used more and more to C++11, I started to see differences, and also often I had thoughts on how to INTERFAC E between the "old" boost and the "new" C + + types?

And as C + + moves forward, especially the library features is available to a certain extend in boost. Boost::filesystem Is the most obvious library which already exists today and have made its-to through standardization, soon being a TS and Most likely part of C++1Y. Boost::thread already offers future::then, maybe the TS for concurrency also would leads to an executor and taskbased Parall Elism Library in Boost. While C + + standardization takes it time, boost can move much more quickly, and implement features earlier, then they is In the standard. Actually, boost has with the last versions largely adopted to C++11, F.E. Boost::thread offers today a similar (and more ADV anced as Future::then) interface as Std::thread.

So, for this blog entry, I do look at boost:: And Std::function, the Smartpointers, and Std::thread/boost::thread in Orde R to look at concepts used in boost templates such as lockable. Please remember, the code was for doing tests, in real life this would happen in more complex code, and maybe not that visib Le to you. All Testcode are compiled (or not) with GCC/MINGW 4.8

function

Some test code to mix boost:: And std::function:

voidMyFunc () {STD::cout<<"MyFunc"<<STD:: Endl;}voidBfunc (boost::function<void() > Bfunc) {bfunc ();}voidStdfunc (STD::function<void() > Stdfunc) {stdfunc ();}structfoo{intI Foointi): I (i) {}voidBarintx) {STD::cout<<"Foo::bar"<< I <<" "<< x <<STD:: Endl;}};

So, this is the test setup. What I would as to test with the if I can exchange the types for one another. A lot of code uses boost::function for callback types, and I wasn ' t sure if for example Boost::function would Stance of Std::function. Lets Test:

std:: Function<void() > Stdfunc = MyFunc;//STD:: Bind(MyFunc);Boost:: Function<void() > Bfunc = Myfunc;bfunc (Stdfunc); Stdfunc (bfunc); Foo f (4);std:: Function<void() > Cstdfunc =std:: Bind(&foo:: Bar, &f, at);Boost:: Function<void() > Bstdfunc =Boost:: Bind(&foo:: Bar, &f, at); Bfunc (Cstdfunc); Stdfunc (Bstdfunc);

So with function I start with a little bit special type. Behind The scenes it uses type erasure, so that it can wrap a lot of different things this you can call (functions, bind F . E.). This makes this code above compile, and it works. Only a non-const reference would (of course) is not work, as C + + would tell you which have actually the wrong type. There is clearly some magic, which this works, if it any good is a different question. The type wraps the boost or STD type into a new instance, and which then'll leads to a new level in the call hierachy.

And the answer to the ' is the good question ' is actually no. You should try to avoid this, as the above code leads to a newly wrapped type, each time you do this, there is a new Wrapp ER level added. So for each time we do this, you add a new level of indirection to your call. Or to quote STL:

Constructing a std::function from a boost::function or vice versa are horrible-you ' re paying double penalties. As an STL maintainer, this makes me want to cry more tears than I had eyes for.

So just because it works, doesn ' t mean you should is doing it.

Smart pointers

Here it gets interesting. There is no-on-a shared_ptr can interface over the type boundary between the standard and boost for example. Also, Unique_ptr is a unique to the standard, boost offers scoped_ptr. The versions of the smart pointers in the standard and boost is different!

A Short Example for shared_ptr:

std::shared_ptr<foo>std::make_shared<foo>(5);boost::shared_ptr<foo> bshared = std_shared;

I hope you understand, which is impossible. The obvious solution in this case was to rely on the Type T, and has it implement the behavoir, which for example could be A Clone method. So, the shared_ptr of boost could take a new ownership of a new copy. Also moving might is a valid strategy, but it feels kind of evil to me ...

... but as Eric Niebler pointed off on Twitter, there was a solution to exchange pointers between the both:

template< class T>Boost::shared_ptr<t>Make_shared_ptr (conststd::shared_ptr<t>&PTR) {return Boost::shared_ptr<t>(Ptr.get (), [PTR] (T*){});} template< class T>std::shared_ptr<t>Make_shared_ptr (constBoost::shared_ptr<t>&PTR) {return std::shared_ptr<t>(Ptr.get (), [PTR] (T*){});}

The beauty of this solution are that it keeps the original shared_ptr contained in the deleter alive, if all other original Copies is destroyed. Hence the pointer is all guaranteed to be valid!

Also on shared_ptr, boost::shared_ptr! = std::shared_ptr. Both versions share most of the interface, but add methods not supported by the other. Std::shared_ptr has allocate_shared and Get_deleter, both could is added to boost. The boost version supports arrays (and hence adds operator[]) while the standard version is does only with a custom deleter. It is arguable, if shared_ptr at all should support arrays, as it isn't really a container, and for an array begin ()/end () Would is nice.

With Unique_ptr the situation was a bit different, it had a release method, which gives the ownership of the pointer to the Caller. Initialize a scoped_ptr in boost with a unique_ptr, and which then looses its ownership. But that is a one-to-one-solution. Scoped_ptr would never give up it ownership, so again, if you want to transfer the object and you had to use a clone method/ Copy. A custom non-deleter for unique_ptr are a solution only, if it living shorter then the scoped_ptr. But then, why isn't stick to boost?

tuple
I only took a short look at the tuple, as I ' m not a-tuple guy, I-like-std::tie, but usually don ' t use tuples very often. Boost::tuple have been around for a while, so it isn't unlikely to run into it in the future. So code like that would is rather nice:

std::tuple<int,int,intstd::make_tuple(1,2,3);boost::tuple<int,int,int> btuple = stdtuple;

But in least with boost 1.54 this doesn ' t work. Also again, might not being the best idea to make it work, except it could is fully checked at Compiletime. So, tuple are a good example where there is an incompatability between the boost and the standard type. Also clearly not a big suprise. To overcome this gap, you'll need to write some gluecode or add additional interfaces to your code accepting C++11 types .

Thread
Lets mix boost and Std::thread code, doesn ' t seem like a good idea. Boost::thread is a good example, where I-would prefer boost over the standard. Another one is, as it just now on October ' fully implemented in GCC. But some of the code was in templates, and uses concepts such as lockable, which in my opinion would allow for a Std::mutex Being locked by Boost::lock_guard. As long as all types is template parameters, this would do. But a std::mutex would always allocate a different resource then Boost::mutex. Boost have in this section IMHO the clear advantage, it can and already have implemented things which are very useful (share D_mutexes F.E.), which c++11 does not. So IF, in the case, use Boost::thread, but also in my opinion, when using parallelism, go for task based solutions. Only the write code with the low level locking, when you really know what is doing, and be very careful. Everytime you lock a mutex, might run into a deadlock, just to point at one of the problems witH low-level Threading.

Conclusion

What does? There is the no one fits all solution, when boost was used in your code base, you might stick to using it. Interfacing between the boost types and the standard ones is often tricky. Boost can in this case adopt and add constructors supporting Std::types, where it makes sense. Often the user would have an facing this problem. On the otherhand, shared_ptr shows, and that's leads to code, where the other different copies can exist in parallel. Generic template code using Concepts/interfaces can avoid the problem to a certain extend, but was also only a partial solu tion.

One big advantage of boost is, which on each relevant platform it would use the same implementation (but sometimes with diff Erent backends OFC). So when moving forward to c++14 > 1y > Yz, Boost might provide a earlier version of some libraries. Boost::optional is another good example for this.

So, for your codebase, you had to decide, which rules you want to setup, which versions to use. Mixing or refactoring your code towards the C++11 standard are on most code bases impossible as c++03 are still in use in PR Oduction for years. When only using the types now also available in the standard, it's also possible to drop boost, which would are one less d Ependency. But boost offers so much libraries, which is not part of the any future standard, that's sooner or later, you might want to BRI Ng boost again into your codebase.

The future would show how much boost offers solutions for converting to its types from C++11 standard Library types. Boost would surely not deprecate it own types, so this problem are here and stay, especially with the C + + standard further A Dvancing into new waters.

Of course the language features is does not have this problem.

C++11 and Boost Library