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.
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 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
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.
Is anyone using the GCC 4.4.0 C++0x support in production? I'm thinking about using it with the latest MinGW, but I'm not sure if it's mature enough.
I'm interested in:
TR1 support
auto
initializer lists
IMHO, TR1 support and auto are safe to use. In the case of auto it was one of the first features to be included into the standard and is a relatively small change to the language. I would therefore have no problem using it.
I would be a bit more hesitant about using initializer lists. On some other forums (eg. comp.lang.c++.moderated) there are questions about their behaviour and its possible that they may change closer to the release of the standard.
I'm not using GCC 4.4.0 C++0x support in production but I'm using the TR1 features with the help of the Boost Library http://www.boost.org/.
The Boost Library is well tested and often used in production environments. If you convert to the C++0x standard later the only thing you have to do is changing your include Directives http://www.boost.org/doc/libs/1_40_0/doc/html/boost_tr1.html.
In my opinion it's currently better to use the Boost Library until the standard is finished. It's a much more compiler independent way.
MinGW simply won't compile with '-std=c++0x'. Strange enough, '-std=gnu++0x' works. Anyway it seems buggy and I won't count on it.
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