Boost is essentially a c++03 library (which stimulated the c++11 standard). I'm contemplating of using some boost libraries (those that are not implemented in c++11). If I'm using c++11, does boost compile (there may be issues with non-copyable but movable objects)? and how well is boost making use of the c++11 features (variadic templates are an obvious thing to use [by some boost libraries] instead of much of the boost MPL)? (I couldn't find this amongst the boost FAQ).
Boost is moving towards using C++11 features.
But one thing to remember is that boost is not "a library", but rather a collection of libraries. Some of them (for example boost::array) probably won't ever be updated to use many c++11 features. Why should it, when you have std::array in the standard (which was based on boost::array?)
On the other hand, Boost would like to remain useful for people who are still using C++03.
Note: Even though I write as if "Boost" is some monolithic entity, there are lots of people who contribute to boost and they have many different opinions. ;-)
To see how well various boost libraries work with C++11 compilers, you can check out the Boost Testing web page.
C++11 was made do be as backwards compatible as possible. Unless boost is using reserved keywords that are new to C++11, there is no reason I know of why it shouldn't compile just fine with the new standard.
Related
Starting in C++11 (I think) a lot of Boost functionality was available in the STL, or in an extension TR1 (again, if memory serves).
I'm struggling to tell specifically which things were and were not included in C++11 and later versions (and in MSVC++ versions).
Specifically this very old question about joining vector<string> has a nice Boost-based answer: https://stackoverflow.com/a/6334153/197229.
I don't want to add boost dependency to my project so - is this functionality now available in standard libraries?
boost::algorithm::join is not part of the C++ standard library. (nor something with equivalent functionality).
More generally, sometimes things are implemented in Boost.Algorithm and then proposed for standardization (Boyer-Moore, for example), and sometimes I implement things that have been added to the standard library in Boost.Algorithm for people who can't/won't use the latest C++ version (any_of, for example).
boost::algorithm::join has not made its way into the standard library as of yet. There is an open paper (N3594) to have it added to the library, but it is sitting in the Library Evolution working group currently.
You'll either need to use one of the other implementations from that Q&A pair or include boost.
I work in a specific enterprise environment and there's no C++11 infrastructure at the moment. Recently I started writing unit-tests and decided to utilize Boost.Test framework since Boost is known for its' portability and enterprise-readiness.
While general BOOST_AUTO_TEST_CASE work great, I found out that dataset tests (BOOST_DATA_TEST_CASE) end up including boost/test/data/monomorphic/fwd.hpp that includes <tuple> unconditionally.
Does DATA_TEST_CASE indeed require C++11? Is there a way to use BOOST_DATA_TEST_CASE and utilize Boost's built-in tuples and other shipped libs to comply with C++03 standard?
Boost doesn't generally deliberately break c++11 compatibility in existing libraries (though this attitude is changing and you should expect more c++11 requirements in future, see discussions on the boost developer mailing lists).
However new libraries and new features for existing libraries don't adhere to this restriction and generally will require c++11 if that makes the implementation easier/simpler/faster/more reliable etc.
BOOST_DATA_TEST_CASE was only introduced in boost 1.59.0 so is likely to be using c++11.
The general advice is if using an old compiler use an old version of boost. If you want new features upgrade your compiler and use a recent version of boost.
What is the real difference between std::mutex and boost::mutex? Which one is faster in terms of implementation and compilation? Are both of them portable?I read my questions related to it but there is no clear mention of difference . std mutex is supported only since c++11 so the older compilers dont support it . Are boost mutex supported by older compilers or not? If the foremost condition requires the code to be portable , then what should be prefered?
As a default choice you should prefer std::anything to boost::samething because it's a part of standard library and hence is more portable since it doesn't introduce external dependency.
You can't really compare std::mutex and boost::mutex in general because there is no one and only std::mutex, it's implementation depends on the standard library implementation that you are using which usually is a part of your toolchain.
There might be a case when you discover using empirical evidence that std::mutex you are using is in some regard "worse" than boots::mutex. In this case it might be reasonable to switch to it, but only if it's really justified and you have an actual evidence (e.g. performance measurement) of that. Even then it seems like a last resort. It might be better to switch to a different standard library implementation or to a different toolchain or upgrade your current one if possible.
Consider boost as a laboratory for prototyping std features. Many std facilities were originally implemented on boost. The difference is that std takes care of consistency and forward compatiblity, while boost targets new horizons. Nothing prevents boost from applying breaking changes in forth coming versions, but it also provides answers to more questions than std. My personal preference is std first - when possible - and boost next - when needed. I generally avoid pre c++11 platforms, unless I am forced to face.
# std::mutex for me every time, for the reason #Henri states it is (obviously) part of the C++ standard so you can rely on it being available everywhere.
Using boost, on the other hand, means that you have to link against the boost library. While this is widely available and offers a number of handy extra features it's quite heavyweight and you wouldn't want to pull it in just for this.
Also, std::mutex may be faster. The cross-platform nature of boost means that things that rely on OS support (which would include mutexes) can sometimes be less efficient. But this would not be a major factor in my thinking.
But if measuring performance is important to you, you should run your own benchmark. You can do this (roughly) over at (say) Wandbox - they support the boost library there.
The focus of Boost is trying new techniques and introducing new capabilities. The focus of the C++ standard is specifying requirements in a way that (in most cases) can be implemented portably. A number of features from boost have found their way into the C++ standard, but were often changed quite a bit in that transition - to improve portability, sometimes improve reliability, etc.
If your implementation (compiler and library) is C++11 or later, and you intend to not to port to older implementations, then definitely use std::mutex. It is part of the standard, from 2011, so preferable. No need to rely on third-party libraries. You will only need boost if you need bleeding edge features of boost that the C++ standard does not support (which means things other than mutex).
Some exceptions to the above: there are some features of boost (including related to threading and mutexes) that haven't made their way into a C++ standard, and some features in the C++ standard that are not in boost.
If you need to use (or support or port to) an older implementation, then consider using boost::mutex. You will, in most cases, need to install a version of boost separately, with your chosen implementation (some compiler versions have shipped with a version of boost, but don't rely on it). If there isn't a version of boost that works with your compiler/library, then (to state the obvious) you will not be able to use boost::mutex.
Boost has had the thread library (which includes mutex) since about version 1.25.0, which dates from late 2001. Which suggests boost is an option if your compiler is no older than (rough guess) early 2000s.
If you need to support an implementation that is significantly older than the early 2000s, then you may be out of luck using boost::mutex, and will need to resort to other libraries/frameworks or get your hands dirty writing OS-specific code.
I am new user of the boost library. I find my self thinking more about adopting boost for a number of reasons. From what I can tell, it seems that the boost library is a sort of skunkworks sandbox where various C++ TR features for upcoming standardization are tried out before being adopted by the C++ committee - think boost::filesystem and boost::regex,
As an example, I was trying out some of the C++11 regex features in visual studio via the #include header - this worked great until I ported to a target power pc platform, which, at the time used CodeSourcery's GCC 4.7.3. Unfortunately, I realized that at run-time, that much of the regex implementation was incomplete or empty (even thought it compiled) - With a bit of homework, I should have realized this beforehand, however now that GCC 4.8.x is out, the implementation is part of the v3 standard C++ library so it is a different story now.
In an ideal world, the standard library should be like developing for Java - write once, deploy everywhere - but that is not a reality. I would eventually like to move to the standard library implementation rather than Boost's regex and filesystem implementations.
My question given the above regex history, is how should developers use boost, is it possible to do a simple search and replace of the boost headers and namespaces when the features are adopted by the standard library or are there more many things to consider. I would like to use pure C++11 code without dependency on 3rd party libraries.
The amount of work required to move from a Boost library to its C++11 conterpart depends on the degree of C++11 conformance of a particular Boost library. In the simplest case it can be a matter of including another set of headers and using another namespace.
In a more complicated case, Boost library may have some subtle incompliancy with C++11 (eg. in Boost.Thread V1 ~thread used to call detach()) - such things might "silently" break the code correctness, but they are easy to fix.
Finally, Boost library may implement funcionality that doesn't exist in C++11 (eg. boost::bind can be extended using get_pointer function). Apparantly, porting such a code to C++11 would be quite not trivial.
Let's begin with your statement
I would like to use pure C++11 code without dependency on 3rd party
libraries.
It is clear that this is not possible now. You will have to use 3rd party libraries for any non-trivial program.
Unfortunately, C++ with Boost is not a platform also. You need 3rd party libraries to do things available out of the box in languages like Java, C#, Python etc.
So, you have to select libraries according to your requirements: performance, supported platforms, multithreading etc.
Again, Boost shouldn't be your default choice. It is not that useful now as it was 10 years ago. Most of must have stuff went into C++ standard library already.
If you support existing C++ codebase, find the best C++ library for your needs (e.g. re2 for regex). If you start a new project, I would suggest using Qt as a platform.
A "simple" way to migrate usage may be to use preprocessor defines to define a "Using Boost" directive. By putting all boost code in an #if-#else and carefully writing the code to not break (or at least have expected results) for sections that do not have a C++11 equivalent. You can simply not provide a definition for "Using Boost" before at the beginning of your code and C++11 features would be used instead.
See this and this
One link points to an old stackoverflow question, the other to an interesting talk performed by Stephan Lavavej
what will happen with the overlapping portion of boost once C++0x becomes mainstream?
Will boost still contain everything it used to, or will they adapt the library to update it with the new std:: stuff?
Will boost have both a normal c++ version and a c++0x version that they will maintain?
One would hope that Boost continues to support existing classes, for a couple of reasons.
First, there is a body of code that uses the overlapping features in Boost that needs to be supported, for some time.
Second, overlapping implementations allow me to select which one I'd prefer to use. There might be some difference between std::Frob and Boost::Frob that is important to my project, and having a choice is good.
In the long term, though, I would expect a migration toward the standard from both the application writers and the tools providers. That makes it a less risky choice to go with std::.
I am not affiliated with Boost and have no they idea what they will do but it seems like Boost will be left untouched.
There already has been released TR1 (VS 2008 feature pack) and Boost was left untouched. Since many users have not adopted Boost or TR1 yet, my prediction is that for at least next five years boost and c++0x libraries will exist in different namespaces and availaible for C++0x users as well as C++ users.
Namespaces make this somewhat of a non-issue for the Boost developers. There is no direct contention between the boost libraries and the standard libraries because they exist in separate namespaces. Therefore, changes to namespace std (for example the addition of std::tr1) have no direct impact on Boost.
Note however, that if you are importing both libraries (std and boost) into the global namespace, then you will have issues.
The following quote from the Boost TR1 documentation also sheds some light regarding Boost's implementation of TR1 components, suggesting that the corresponding Boost library will be maintained for the foreseeable future:
The TR1 library provides an
implementation of the C++ Technical
Report on Standard Library Extensions.
This library does not itself implement
the TR1 components, rather it's a thin
wrapper that will include your
standard library's TR1 implementation
(if it has one), otherwise it will
include the Boost Library equivalents,
and import them into namespace std::tr1.
Do you mean tr1?
Boost already supports tr1.
All the classes from boost that have been adopted into std::tr1 are available in this namespace from boost. See the following documentation.
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_tr1.html