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.
Related
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.
This is a very uninformed question, but:
I would like to start using C++11. Can I continue to use my large collection of libraries which were compiled with my old gcc 4.2.1 compiler or do I need to recompile them all with a new compiler? I would think (or hope) the answer is no, but I am only a dabbler.
So that I may have at least part of my ignorance removed, can you explain why in either case?
Thanks
Yes, you should.
The weaker reason is not binary compatibility, the problem is about expectations. A C++11 enabled compiler will expect a number of features to be available (move constructors among them) and use them when appropriate. And that's only scratching the tip of the iceberg, there are several other incompatibilities (auto, 0 and its interaction with pointers, ...).
It means that any inline method in a header may suddenly be interpreted differently, in light of the C++11 Standard.
The stronger reason is that each version of the compiler comes with its own Standard Library implementation. You don't really want start mixing various versions around and especially not when they have undergone such major changes (once again, rvalue references...).
Believe me, it's simpler to recompile now rather than having that nagging thought that each bug that appear may be due to an incompatibility between old and new libraries...
It's a compiler question. For instance, if you have a single compiler which supports both C++03 and C++11 depending on a compiler switch, you can very likely mix libraries. There's nothing new in C++11 that forces an incompatibility with C++03.
Howeve, you mentioned that your libraries were compiled with GGC 4.2.1. Since C++11 was just an idea back then, it's quite likely that GCC back then was implemented in ways that turned out to be incompatible with C++11.
For instance, std::list::size() must be O(1) in C++11, but it could be O(N) in C++03. GCC chose a O(N) implementation back then, not knowing the future requirements. The current GCC std::list::size implementation is compatible with both C++11 and C++03, since O(1) is better than O(N).
The answer totally depends on the API of your library and its implementation dependencies.
The conditions that guarantee that you don't need to recompile are:
-- Your library doesn't use C++ specific features in its public API.
That implies:
Your library doesn't provide classes/class-templates/function-templates/other C++ specific stuff.
You don't accept/return C++ classes to/from your library functions.
You don't pass function parameters by reference.
You don't provide public inline functions with C++ specific implementations.
You don't throw exceptions from your functions.
You don't (because you have no reason to) include C++ specific library headers in your public headers. (It wouldn't hurt if you do include them but everything must be OK if you remove such includes. It is like an indicator.)
-- Your library depends only on the libraries that binary-compatible with those available in your new build environment.
If those conditions are not satisfied then there is no guarantee that your library will work correctly. In most cases it is much easier to recompile than to make sure that everything works correctly.
Either way if you are going to make binary compatible API that satisfies the conditions above then it is much better to design and implement C language API. This way you automatically satisfy the above conditions and don't fall into sin of writing C-style C++ code.
You can use large parts of C++11 without recompiling (assuming ABI compatability), but a particular important part, for me atleast, will not be accessible to the already compiled code - move semantics.
Move semantics can make your code faster just by recompiling with a C++11 compiler (and preferably, a C++11 stdlib).
There are also other reasons. Maybe your preferred library has become C++11 aware since you last compiled it, and is now more efficient, safer or easier to use if compiled with a C++11 compiler?
For your own libraries, with C++11 you surely can make it them more efficient, safer and easier to use? :)
If your interfaces to the compiled code uses any template which was modified by C++11, then yes, you have to recompile. Otherwise you probably can continue to use your old libraries (unless the compiler provider also decided to make changes of the ABI at the same time, because it's a great opportunity to fix long-standing ABI bugs which are otherwise often refrained from fixing because of binary incompatibilities).
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).
I would like to enable support for C++0x in GCC with -std=c++0x. I don't absolutely necessarily need any of the currently supported C++11 features in GCC 4.5 (and soon 4.6), but I would like to start getting used to them. For example, in a few places where I use iterators, an auto type would be useful.
But again, I don't need any of the currently supported features. The goal here is to encourage me to incorporate the features of the new standard into my programming "vocabulary".
From what you know of the C++11 support, is it a good idea to enable it in GCC, and then embrace it by, for example, switching from using boost::shared_ptr to std::shared_ptr exclusively as the two don't mix?
PS: I'm aware of this good question which compares the different flavors of shared_ptr but I'm asking a higher level advice on which to use before the standard is finalized. Another way of putting that is, when a compiler like GCC says it supports an "experimental feature", does that mean I am likely to encounter weird errors during compilation that will be major time sinks and a source of cryptic questions on StackOverflow?
Edit: I decided to switch back from std::shared_ptr because I just don't trust its support in GCC 4.5 as shown by example in this question.
There are a couple of reasons to switch over to std::shared_ptr:
You remove a dependency on Boost.
Debuggers. Depending on your compiler and debugger, the debugger may be "smart" about std::shared_ptr and show the pointed to object directly, where it wouldn't for say, boost's implementation. At least in Visual Studio, std::shared_ptr looks like a plain pointer in the debugger, while boost::shared_ptr exposes a bunch of boost's innards.
Other new features defined in your linked question.
You get an implementation which is almost guaranteed to be move-semantics enabled, which might save a few refcount modifications. (Theoretically -- I've not tested this myself) As of 2014-07-22 at least, boost::shared_ptr understands move semantics.
std::shared_ptr correctly uses delete [] on array types, while boost::shared_ptr causes undefined behavior in such cases (you must use shared_array or a custom deleter) (Actually I stand corrected. See this -- the specialization for this is for unique_ptr only, not shared_ptr.)
And one major glaring reason not to:
You'd be limiting yourself to C++11 compiler and standard library implementations.
Finally, you don't really have to choose. (And if you're targeting a specific compiler series (e.g. MSVC and GCC), you could easily extend this to use std::tr1::shared_ptr when available. Unfortunately there doesn't seem to be a standard way to detect TR1 support)
#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
using boost::shared_ptr;
}
#endif
I suppose it depends how much you use boost. I personally only use it very sparingly (in fact the random number library, in a single project). I've recently started using -std=c++0x for my other projects, and I use the new std:: library features like shared_ptr in them. I like my projects to have the minimum of dependencies, so I'd rather be dependent on the compiler's standard library implementation than on boost.
But I don't think there is a one-size-fits-all answer to this question.
You should always use std::shared_ptr wherever possible, if it's available, instead of boost. This is basically because all new interfaces which use shared_ptr will use the Standard shared ptr.
It's probably not a bad idea to start getting into the habit of using std::shared_ptr when allowed by the compiler. Since the interface is the same as boost's shared_ptr you can always switch back if you needed to.
If you are just building on the one platform that is fine (make the switch)
(Note: You do have unit tests to validate backward compatibility don't you?)
If you compile on multiple platforms is where it becomes a little more awkward as you need to validate that the features on g++ 4.5 are available on all the platforms you use (ie building for MAC/Linux the default Mac g++ compiler is still a couple of version's behind the default compilers on Linux).
Another reason to switch over to std::shared_ptr:
it supports std::unique_ptr, i.e. has constructor.
boost::shared_ptr doesn't.
Aside from implementation consistency, boost::shared_ptr currently retains at least two niche advantages over std::shared_ptr:
The availability of boost::make_shared_noinit. It's particularly useful in conjunction with arrays, avoiding both the cost of zero-initialization and the overhead of separate allocation. (FWIW, it's also a proposed addition to the standard.)
Boost.Python makes special use of boost::shared_ptr's support for type-erased custom deleters, but doesn't yet do the same for std::shared_ptr.
I found std::shared_ptr to be faster than boost::shared_ptr. I did a test, you can review the code and see the pie chart results comparing boost, Qt, and std shared pointers.
https://www.osletek.com...
The spate of questions regarding BOOST_FOREACH prompts me to ask users of the Boost library what (if anything) they are doing to prepare their code for portability to the proposed new C++ standard (aka C++0x). For example, do you write code like this if you use shared_ptr:
#ifdef CPPOX
#include <memory>
#else
#include "boost/shared_ptr.hpp"
#endif
There is also the namespace issue - in the future, shared_ptr will be part of the std, namespace - how do you deal with that?
I'm interested in these questions because I've decided to bite the bullet and start learning boost seriously, and I'd like to use best practices in my code.
Not exactly a flood of answers - does this mean it's a non-issue? Anyway, thanks to those that replied; I'm accepting jalfs answer because I like being advised to do nothing!
The simple answer is "do nothing". Boost is not going to remove the libraries that got adopted into 0x. So boost::shared_ptr will still exist. So you don't need to do anything to maintain portability.
Of course, once 0x is here, a lot of code can be simplified, cleaned up and optimized, but since it's not yet here, that work can't really begin. All you can do is make sure your code will still compile when 0x hits... and it should, just like that. Boost isn't going to delete half their libraries. (I'm not guessing. They've stated this on their mailing list before)
(and if you want to switch to the standard shared_ptr, I'd say it's probably easier to just do a simple search/replace when the time comes. Replace #include <boost/shared_ptr.hpp> with #include <memory>, and boost::shared_ptr with std::shared_ptr)
Or of course, you can just decide on the project that you're going to keep using Boost's shared_ptr. Just because it's been added to the standard library doesn't mean you have to use it, after all.
Nothing will need to be done because of namespaces. If you want to use the boost implementation you will still use the boost namesapce.
I don't think they would venture into breaking compatibility in such a big way with a previous version.
See my previous similar question here: what will happen with the overlapping portion of boost once C++0x becomes mainstream?
But of course if you do using namespace a lot in your code you may have some overlapping definitions. You'll have to go back to specifying the namespace explicitly on each use.
The best way to use shared parts between C++0x and Boost is to use the Boost.TR1, i.e; the implementation if the Technical Report already accepted. Boost.TR1 will use the implementation provided by the compiler when it is available, and the provided by Boost otherwise. This was the main goal of Boost.TR1
"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. "
No we don't, as of yet, given the facts that:
support for C++0x is not yet upto the mark across the various platforms (we need) and
that it is yet to be declared a standard officially
But yes, we do use Boost as and when required (but of course, only after a release has gone through a sanitation phase do we use it) just like any other third party library that we use. Also, we use the source form on a as-needed basis.
There is however an effort towards more stringent adoption of the driving principles in product design phase (e.g. move-ctor etc).
There is definitely going to be some work when C++0x gets standardised; but that will also require us to move on to some of newer compilers (vc10?) and moving on to a new compiler is always a task in it's own.
You may actually always prefer using the Boost version for a long time. Especially if you need to compile on multiple platforms.
The Boost libraries are ported and tested on multiple platforms and behave the same there (most of the time.)
The first vendor implementations of the new C++ libraries may still contain minor bugs and performance differences just like it was such a mess when STL and the std namespace were added.