I'm trying to get my program working without boost usage, but can't find an alternative of some useful patterns. Namely, I can't find boost::optional-likewise pattern in the standard library. Is there some standard alternative for boost::optional (C++11 or somewhere else)?
Short answer: No.
Long answer: Roll your own according to the boost spec. The documentation is quite exhaustive and the code isn't that complex, but this still requires above average C++ skills.
To update this answer: C++14 unfortunately did not ship with std::optional. The current proposal (Revision 5) is N3793 and it is expected to be shipped as a separate technical specification or to become part of C++17.
There is currently a proposal for C++14 (or C++17). So the answer is (probably) not yet :).
Like pmr explained, it is not possible right now, and will not be until C++17 is out.
However, you should be able to use this single header library on github as a drop in replacement of boost- or std optional. It has no dependencies (except a c++11/c++14 capable compiler).
Related
Very easy question but I've got so used to finding boost functionality as part of STL in C++11 that I was surprised when I couldn't see a join function.
Just to double check - it's definitely not present in C++11? Is it part of any newer versions of the C++ standard?
There is no std::join in C++11 or C++14 so you will still have to use the boost version. There is an open proposal for it N3954
Accorging to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/sd-1.htm The papper has been mailed out and is in the "Library Evolution" sub group.
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.
for example boost::function is moved almost entirely to std::function, the same is with boost::shared_ptr
But I can't find std::any?
Was it renamed or was not it placed in new standard at all by any reason?
Since the question was asked, we advanced towards std::experimental::any as an optional feature voted out of C++14 standard.
It was then implemented in GCC 5.1, at least.
The feature was since then standardized in C++17 resulting in std::any. See also C++17's std::variant for a type-safe union which either holds one of a limited known-types alternative, or is empty (thanks remy-lebeau for the tip).
Not every library from boost makes it into the standard (and even those that do may have components removed). Generally the commitee is pretty conservative when it comes to adding to the standardlibrary (since it's next to impossible to get something removed at a later point if the inclusion was a mistake (.e.g. because there is a better alternative)).
boost::function and boost::shared_ptr where pretty much a given for inclusion since they where already part of tr1. boost::any on the other hand did not make the cut. It might however be included in the standard library at a later point (e.g. in the next technical report, look here). While boost::any is nice to have, I wouldn't rate it as quite as important as e.g. shared_ptr.
Concluding: boost::any is not part of C++11, since the committee didn't see any pressing need to include it
Std::any was recently accepted into the c++17 standard:
http://en.cppreference.com/w/cpp/utility/any
I think the default position was that a library would NOT be included in the new standard unless it was submitted to be included and then passed the committee.
I am not sure if boost::any was ever submitted. Probably not. However you can still use boost::any.
My guess is that with C++11 boost libraries will be rewritten, some will be considered redundant and others will be changed to use move semantics, initializer lists and auto thus being written in C++11 style with C++11 features.
Most likely new libraries will all be in C++11 but existing boost packages will be kept as available for some time to come as many will not have switched to C++11 compilers yet. I would also guess that only features of C++11 that are implemented by all the main compilers will go into the package at first.
This is probably more a question for programmers than stackoverflow, and even better for comp.std.c++.moderated and boost mailing lists.
std::sort(range(c));
as opposed to
std::sort(c.begin(), c.end();
Do you expect the next standard to provide range overloads for standard algorithms?
Boost's range iterators are something similar, and Bjarne Stroustrup's iseq()s mentioned in TC++PL3e are also the same idea. I have looked at the latest draft I could find but didn't see range overloads mentioned.
The History page provides a partial answer.
There has to be a compelling need to add overloads to the std namespace. Note, this is a Library Issue. You can search the archives to find if anyone has previously raised a request to add these to the library. If there isn't any you can submit a defect report. The current language does not, in any way, stop you from writing your own wrappers. So, the question boils down to whether a lot of others will also want this as a standard library supported feature or not. But that ain't all. Any extension, even to the library, is not just a technical choice, but is also guided by numerous other geo-political issues. You have to have a certain number of votes to get this in.
Frankly, I'd love to see this get in. However, remember this in no way is a novel/core feature that the library can't do without. So, keep your fingers crossed.
The range-based for loop is the only thing in the draft standard I could find that uses the Range concept. It seems natural to me that most of the standard algorithms could support Ranges, but there's no mention of it in the draft standard you linked.