Are some of the trunk regression tests running in C++0x mode when they shouldn't be?
Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be. for example: Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x" If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them. Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it? Thanks, Richard Webb
Hi Richard, On Nov 10, 2011, at 10:29 AM, Richard Webb wrote:
Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be.
for example:
Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x"
If you look at the test results for assign, there are rvalue- reference related errors in toolsets which shouldn't have them.
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
Yes, there's been a bug that I've been unable to track down. Note that if -std=c++0x option were actually in the user-config.jam file, then no 3.4.6 test could pass, they'd all fail. Since many 3.4.6 tests are passing while some libraries are failing wholesale, I'm not sure quite what to make of this. If all of 3.4.6. was failing I could easily track it down. Since only some of the libraries are failing with this flag, I'm less clear where to look for the problem. I've been watching this behavior for some months now, it first appeared about less than a year ago. -- Noel
AMDG On 11/10/2011 09:29 AM, Richard Webb wrote:
Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be.
for example:
Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x"
If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them.
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. In Christ, Steven Watanabe
Steven Watanabe <watanabesj <at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372.
How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c? Gennadiy
Le 10/11/11 21:13, Gennadiy Rozental a écrit :
Steven Watanabe<watanabesj<at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c?
You should not require this. Even if using a given version of gcc, users could been to preserve a C++03 behavior. Best, Vicente
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Le 10/11/11 21:13, Gennadiy Rozental a écrit :
Steven Watanabe<watanabesj<at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c?
You should not require this. Even if using a given version of gcc, users could been to preserve a C++03 behavior.
What is the problem with enabling C++11 features if possible? We do not expect backward compatibility issues, don't we? What about MSVC? It has C++11 enabled by default. Some of the new features of Boost.Test require c++11 support. I want to be able to test it and I want users to be able to use it. Gennadiy
On 10 Nov 2011, at 23:30, Gennadiy Rozental wrote:
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Le 10/11/11 21:13, Gennadiy Rozental a écrit :
Steven Watanabe<watanabesj<at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c?
You should not require this. Even if using a given version of gcc, users could been to preserve a C++03 behavior.
What is the problem with enabling C++11 features if possible? We do not expect backward compatibility issues, don't we?
What about MSVC? It has C++11 enabled by default.
Some of the new features of Boost.Test require c++11 support. I want to be able to test it and I want users to be able to use it.
There are two problems with enabling C++11 unconditionally in gcc: 1) It breaks binary compatability of some stl containers 2) Different versions of gcc support different amounts of C++11. In particular, there are at least 2 (maybe 3?) different semantics for rvalue references floating around. In general, I would advise only trying to use boost in C++11 mode in g++ 4.5 at least. I don't think it's worth the effort to make boost work with each of the early partial implementations floating around in the various compilers. Chris
on Thu Nov 10 2011, Christopher Jefferson <chris-AT-bubblescope.net> wrote:
On 10 Nov 2011, at 23:30, Gennadiy Rozental wrote:
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Le 10/11/11 21:13, Gennadiy Rozental a écrit :
Steven Watanabe<watanabesj<at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c?
You should not require this. Even if using a given version of gcc, users could been to preserve a C++03 behavior.
What is the problem with enabling C++11 features if possible? We do not expect backward compatibility issues, don't we?
What about MSVC? It has C++11 enabled by default.
Some of the new features of Boost.Test require c++11 support. I want to be able to test it and I want users to be able to use it.
There are two problems with enabling C++11 unconditionally in gcc:
1) It breaks binary compatability of some stl containers 2) Different versions of gcc support different amounts of C++11. In particular, there are at least 2 (maybe 3?) different semantics for rvalue references floating around. In general, I would advise only trying to use boost in C++11 mode in g++ 4.5 at least. I don't think it's worth the effort to make boost work with each of the early partial implementations floating around in the various compilers.
3) The committee made some breaking changes to the language (not many, but still)... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Christopher Jefferson <chris <at> bubblescope.net> writes:
There are two problems with enabling C++11 unconditionally in gcc:
1) It breaks binary compatability of some stl containers
Does this mean that library and executable needs to be built with the same value of this flag?
2) Different versions of gcc support different amounts of C++11. g++ 4.5 at least.
I am fine with enabling it for gcc 4.5+ Gennadiy
AMDG On 11/10/2011 03:30 PM, Gennadiy Rozental wrote:
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Le 10/11/11 21:13, Gennadiy Rozental a écrit :
Steven Watanabe<watanabesj<at> gmail.com> writes:
Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it?
This is a problem in Boost.Test as of r75372. How should I specify in Jamfile that I want to require c++11 support from gcc starting with version a.b.c?
You should not require this. Even if using a given version of gcc, users could been to preserve a C++03 behavior.
What is the problem with enabling C++11 features if possible? We do not expect backward compatibility issues, don't we?
The problem is that as a library developer, it isn't your decision whether to enable it or not.
What about MSVC? It has C++11 enabled by default.
Some of the new features of Boost.Test require c++11 support. I want to be able to test it and I want users to be able to use it.
It's better to let users decide whether they want C++11 support. For testing, just look at the testers that have C++11 enabled. Most of them have _0x in the name. For your own testing you can pass cxxflags=-std=c++0x on the command line. In Christ, Steven Watanabe
Steven Watanabe <watanabesj <at> gmail.com> writes:
What is the problem with enabling C++11 features if possible? We do not expect backward compatibility issues, don't we?
The problem is that as a library developer, it isn't your decision whether to enable it or not.
[snip]
It's better to let users decide whether they want C++11 support.
Ok. I mostly agree, even though MSVC enabled these by default and gcc users will have to make extra effort.
For testing, just look at the testers that have C++11 enabled. Most of them have _0x in the name. For your own testing you can pass cxxflags=-std=c++0x on the command line.
Ok. Let me look into making this change. I guess I'll need to put this in documentation. Gennadiy
participants (7)
-
Belcourt, K. Noel -
Christopher Jefferson -
Dave Abrahams -
Gennadiy Rozental -
Richard Webb -
Steven Watanabe -
Vicente J. Botet Escriba