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
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.
I am using C++ in Xcode version 8.1. I need to use the functionality of boost::any but am strongly opposed to pulling any part of Boost into our project (let's not debate it please).
I see that std::any is "merged into C++17" here.
I want to use this in my Xcode 8.1 project. I have tried using -std=c++1z as a custom flag on the project, but I can't seem to find a header for it.
How can I use std::any or std::experimental::any in my Xcode project?
Can I download the appropriate headers from an implementation and throw them into my project's sourcecode? Or, even better, is actually available to now in my version of Xcode/Clang/C++?
You can't say "I want the default Xcode compiler [which has no support for any]" and at the same time request it to support any. You also can't mix standard library headers for different compiler versions.
You can either
use a compiler version that provides std::any or
use any third party library that provides another any-like type.
Your installation setup does not have the c++17 standard. std::any simply is not available to you unless you get a compiler with at least experimental support for what you want.
Clang Cxx Status
You'd have a lot better luck just using boost::any probably.
If you're really set on not bringing a third party library into play, the reality is that creating your own any isn't that difficult. I don't recommend reinventing the wheel but in this case it's not that difficult.
Here's a SO question with an answer showing a way to do 'any'.
It is illegal to inject new types into std via a third party library. You can upgrade your compiler, get a distinct std library your compiler supports, or use a 3rd party library that provides any in another namespace, or write your own.
The first you said no to.
The second is hard, as xcode does not advertise what its compiler actually is. There are generally two common std libraries that work with clang-llvm derived compilers; libc++ and libstdc++. That kind of swap tends to be very expensive even if the other one has the feature you want.
The third is basically "use boost" or equivalent.
The last isn't hard; a few days work (mostly bugs after the fact), based on writing types of similar complexity, assuming "good enough" is good enough (ie, not getting caught up in ideal exception guarantees, or matching standard exactly, etc). An implementation will require hyperbolic effort to approach perfection, naturally.
Xcode 9.0 beta can now be downloaded (https://developer.apple.com/download/). It supports the c++17 flag option.
Edit: Xcode 9.2 is publically available with std::any support.
Many utilities of boost have been included as part of extended C++ TR1 currently.
Is the complete boost library going to be included once the standard is officially out ? In other words, do I need boost library, if I have complete standard conforming C++11 compiler ?
If not then any reason for that (Reliability cannot be an issue; as far as I know it's written by many people from standard committee) ?
Boost is huge, and of generally high but still varying quality. A lot of the APIs - even the techniques and functionality - are quite "experimental" in the sense that they're still regularly modified as real-world feedback comes in. By way of contrast, the Standard is expected to get it right and need minimal revision, especially when that breaks backwards compatibility.
The standard for review for Standard libraries is much higher than boost's, which is not to say that many boost libraries wouldn't meet the bar - just that many wouldn't too, and that the review process itself is time consuming. There are terrific programmers coordinating and contributing to boost, but they naturally focus their time on their own development interests and things they see as more relevant, so if something is a little specialised, doesn't appeal to their coding style, etc. it may not receive the same scrutiny. The Standard library needs to be scrutinised much more thoroughly as the consequences of change are so much more painful.
While portability is a factor in acceptance of a library into boost, it's not a hard and fast requirement, where-as compiler vendors are expected to make the Standard library run on all C++ compilers, so taking boost more or less as-is and expecting the functionality to be universal on Standard-compliant compiler vendors would put a huge workload on those vendors.
No, in fact very few parts of Boost are "included" in the C++0x revisions to the C++ Standard Library. The parts that are "included" are some of the most commonly used parts of Boost, though.
Really, "included" isn't correct anyway: there are many differences between the Boost libraries and the corresponding additions to the C++ Standard Library. Further, the Boost libraries continue to grow and evolve; the C++0x Standard Library is now finished.
No, Boost is not going to be included in its entirety in C++0x.
Parts of Boost will be, like boost::shared_ptr, Boost.Array, and a couple of other things. But most of Boost is not being included.
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