I'm writing some stuff using the tr1 namespace in VS2008. What will happen when C++xx becomes ratified? Has this happened before with other C++ revisions? Will the tr1 stuff still work or will I have to change all of my include? I realize that I'm making the very large assumption that this ratification will someday occur. I know that most likely none of you work for MS or contribute to GCC, but if you have experience with these kinds of changes, I would appreciate the advice.
std::tr1 will become part of std in C++1x (std::tr1::shared_ptr becomes std::shared_ptr, etc). std::tr1 will continue to exist as long as that compiler claims to implement TR1. At some point your compiler may drop that claim, and drop std::tr1 as a result. This probably will never happen.
std::tr1 has already been "copied" into namespace std in Visual Studio 2010 Beta (via a using directive)
The Wikipedia entry for C++0x says "A large part of the new libraries are defined in the document C++ Standards Committee's Library Technical Report (called TR1), which was published in 2005. Various full and partial implementations of TR1 are currently available using the namespace std::tr1. For C++0x they will be moved to namespace std. However, as TR1 features are brought into the C++0x standard library, they are upgraded where appropriate with C++0x language features that were not available in the initial TR1 version. Also, they may be enhanced with features that were possible under C++03, but were not part of the original TR1 specification."
tr1 is not part of any standard (the paper it is shorthand for never was accepted) - it's just a convention that some compilers provide. They will almost certainly go on providing it long into the future.
Related
Some of the new features that have been added to the recent ISO C++ standards were originally part of boost.
This naturally raises the question of guidelines for writing portable code.
Is there a canonical way to portably use new language features when using an older version of the standard?
If you are already using boost should you continue to use the boost versions or the versions in C++17 or the experimental versions?
How far should you go in trying to be portable?
I am surprised not to find this question as a FAQ somewhere.
Shouldn't there be something about this in the core guidelines, the boost FAQ and or as an ISO committee paper?
There seem to be questions about individual features but less considering the wider view.
For example:
C++11 Polyfills
Aliasing boost::variant or std::variant not compilable
How to correctly shim functionality into std?
There are several projects that provide polyfills.
Boost is not the only option, though it may be the most common and comprehensive.
There are others, for example:
https://github.com/tcbrindle/cpp17_headers
https://www.reddit.com/r/cpp/comments/5oz3zj/c_shims_library/
https://abseil.io/about/philosophy
You can import the appropriate version with using clauses but this is risky as it masks semantic differences
see also:
From boost to std::experimental and furthermore c++17
You might consider using feature test macros
and create headers like "cxx17/optional.hpp" containing:
#ifdef __cpp_lib_experimental_optional
#include <experimental/optional>
namespace cxx17
{
using std::experimental::optional;
}
#elif __cpp_lib_optional
#include <optional>
namespace cxx17
{
using std::optional;
}
#else
#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}
#endif
However this still papers over semantic differences.
In some cases the boost libraries deliberately differ from the standard.
You also have to consider that there is no such thing as portable code
only code that has been ported. You cannot guarantee your code will work
unless you have actually tested it in each environment.
If you attempt to make your code portable like this and have no intention
of running it on those environments its just a YAGNI (you ain't gonna need it).
Using the feature test macros shows you're clever but it could be considered noise if they aren't used.
If you are using boost already it seems safe to assume you can continue using it
and leave it to boost (and the boost maintainers) to detect whether you are using C++17 or a TS
and act according. Unless you have a lot of resources you can assume that
the boost libraries are more portable than your code.
A good thing to do is to document intent.
If you just want to make life easier for future maintainers but you are stuck using
C++11 for now you might consider just doing (in cxx17/import_optional.hpp):
#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}
and using the cxx17 namespace to indicate that you wish to use C++17
but can't yet. This also implies that you consider deviations between boost and the ISO standard a bug
for your project. Other users may just prefer the boost version.
(consider for example What are the differences between std::variant and boost::variant?)
This applies mainly for pure library extensions.
For changes to the language itself you can sometimes emulate them using macros. This can be ugly so it may be better to stick to a given standard.
This should probably be a community wiki but I will wait in case a more learned guru comes up with a better answer.
C++03 is lacking some things I'd love to use: std::shared_ptr, std::function and std::bind.
We can't fully switch to C++11, because the project needs to work with older libstdc++ versions. I know that this stuff is in Boost as well, but we cannot use that for other reasons.
Hence we started to use C++ 0x/TR1, which is supported by all the compiler versions we currently use. But we're having some trouble with it:
There's very little information about what of TR1 is implemented in which version of Clang/MSVC/GCC
I cannot figure out what the -std=c++0x switch does in Clang, compiles fine without it
I'm not sure what namespaces to use, e.g. std::tr1::shared_ptr vs std::shared_ptr
So, the question: Is C++ 0x/TR1 safe to use when portability matters? Is it implemented in all major compilers? Should I worry about proprietary toolchains etc.? Are we better off sticking to C++03?
TR1 is an experiment made by the C++ standards committee. The purpose of the experiment is to get field experience for libraries, with the hope of standardizing them in a future standard.
TR1 is not a normative standard.
The spec of TR1 specifies the use of namespace std::tr1. The reason things were not put into namespace std is to allow the committee more freedom in modifying the TR1 specification on the way to standardization. And yes, modifications were made in places when most of TR1 was standardized in C++11.
The TR1 document begins with these words:
This technical report is non-normative. Some of the library components
in this technical report may be considered for standardization in a
future version of C++, but they are not currently part of any C++
standard. Some of the components in this technical report may never be
standardized, and others may be standardized in a substantially
changed form.
The goal of this technical report it to build more widespread existing
practice for an expanded C++ standard library. It gives advice on
extensions to those vendors who wish to provide them.
Most, but not all of TR1, was widely implemented in in the 2005 time frame across gcc and MSVC. The llvm libc++ was developed after the TR1 time frame and was targeted straight at the new C++11 standard, which moves many TR1 components into namespace std, and makes them normative (required by a standard).
Clang is known to be used with both llvm libc++ and gcc's libstdc++.
I do not know which implementations of the std::lib you need to be portable among. If all of the places you need to port to implement TR1, it is safe, otherwise it is not. But TR1 is not a normative standard. C++98, C++03 and C++11 are normative standards.
Checked just for fun, and it turns out libcxx used in Emscripten is
the issue, not Clang 3.2.
I have coached many, many project owners on how to make their code which uses TR1 portable across libstdc++ (has TR1) and libc++ (has C++11). libc++ places those TR1 components that were standardized into C++11 in namespace std as specified in C++11. It does this even when -std=c++03. This was done as a transition aid. libc++ does not try to be a C++03 conforming library. It's life starts with C++11.
libc++ has a version number macro called _LIBCPP_VERSION. If this macro is defined after include'ing a std-header, you are using libc++, else you are not. So you can write code like this:
#ifdef _LIBCPP_VERSION
// using libc++
#include <memory>
typedef std::shared_ptr<MyType> MyTypePtr;
#else // !_LIBCPP_VERSION
// not using libc++
#include <tr1/memory>
typedef std::tr1::shared_ptr<MyType> MyTypePtr;
#endif // _LIBCPP_VERSION
Note that you must have first included some std-header for _LIBCPP_VERSION to get defined or not. If you need to gratuitously include a std-header to see if _LIBCPP_VERSION gets defined, use:
#include <ciso646> // detect std-lib
C++98/03/11 specify <ciso646> to do absolutely nothing. So it is very cheap to include. The libc++ implementation of this header does nothing but define _LIBCPP_VERSION.
Once done, your code can now easily switch among libc++ and other libraries which implement TR1.
Instead of trying to make TR1 work on all your different compilers, I would just take the boost code (header-only) and copy-paste it into your own project (since you can't use boost directly for whatever reason). The boost versions are well supported and debugged, and will work consistently across any C++98 compiler that is supported by boost.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm reading Boost array documentation and I see this line :
If you are using C++11, you should consider using std::array instead of boost::array
I was under the impression that Boost, for its major libs, was always preferable to standard lib because :
boost will never perform worse than the standard lib
boost may provide more features
boost is at last of equal quality than standard lib (people writing the C++ standard are active boost developpers/supervisors)
major boost features end up in the standard lib a few years later
So am I right to prefer boost over stdlib ?
If not / more complicated, which of my assumptions are to be corrected ?
I think you should use standard lib when available because... it's standard and comes with the compiler. Besides, if you use boost you need an annoying external dependency.
So, my advice is: use std when possible. If you're writing portable code, that must also be compiled with old compilers, you can consider to use your own namespace (e.g.: cxx0x) that embeds std or boost namespace according to the compiler you're using (this is called namespace alias):
#ifdef COMPILER_HAS_CXX0X
#include <memory>
namespace cxx0x = std;
#else
#include <boost/shared_ptr.hpp>
namespace cxx0x = boost;
#endif
...
cxx0x::shared_ptr<MyClass> = ...
Taken from the Boost people themselves:
Why should an organization use Boost?
In a word, Productivity. Use of
high-quality libraries like Boost
speeds initial development, results in
fewer bugs, reduces
reinvention-of-the-wheel, and cuts
long-term maintenance costs. And since
Boost libraries tend to become de
facto or de jure standards, many
programmers are already familiar with
them.
Ten of the Boost libraries are
included in the C++ Standard Library's
TR1, and so are slated for later full
standardization. More Boost libraries
are in the pipeline for TR2. Using
Boost libraries gives an organization
a head-start in adopting new
technologies.
Many organization already use programs
implemented with Boost, like Adobe
Acrobat Reader 7.0.
From my own experience I prefer to use boost for now. Maybe it's historical, but I found the STD attempts in TR1 that came with VC2008 had too many bugs, in spite of PJ Plauger's best efforts, he couldn't reproduce the quality of the peer-reviewed and checked code of boost that had gone through quite a bit of history.
Unless they can actually take the boost code and use it in STD, why would they reproduce it better? Of course sometimes they might, and really they should work together on it rather than against each other.
One thing I do now though is declare an alias namespace, usually called spns thus:
namespace spns = boost;
after which I can use spns::shared_ptr throughout my code (spns stands for "shared pointer namespace") and if we ever change to std later it will be easy to go to one place and edit just that line and the include.
When it comes to C++11, there are major changes to the Standard and boost's code is C++03. So now the tables are likely to turn for certain parts of the library. I reckon some of boost's fine libraries will become almost obsolete for C++11, e.g. nobody will use boost::lambda anymore, they will just use the new language syntax for a lambda.
So yes, when you move to C++11, it may be time to abandon parts of the boost library and use the new versions.
The trend that I have seen in open source software developed against C++11 is to move API-compatible (subset of) features from STD to boost - because boost is available for non-C++11-compatible compilers where the std features are (obviously) not.
Good example of this is mosh.
For API-compatible features, it's simply a matter of switching namespaces around. In fact, no reason not to make it a configuration option, if you can.
Sidebar: if you're linking against the latest version of non-header-only boost libraries, be forewarned that certain features are no longer available unless boost was compiled with -std=c++11. I ran into this recently with certain functions in the boost::filesystem API.
If something can be standard let it be standard.
If something cannot, use the solution more standard as possible (and BOOST is designed for that)
Many standard library feature are taken from boost, that continue to exist to support application that where deployed when those feature where not yet been standardized.
Using boost for standardized feature is in fact a "look backward". Sometime necessary (may be the standard library specific implementation does not include all what is required ... it is typical to see boost::thread instead of std::thread on windows because of a std implementation not yet been ported by some compilers) but I would not make it a rule.
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.
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