Preparing for the next C++ standard

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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. "