The C++ committee has been working on the upcoming revision of the ISO C ++ standard, C++0x, which will include several new features that are likely to be of interest to Boost developers and users. As C++0x draws nearer, we are starting to see preliminary implementations of C++0x features. We need more experience with the use of these new language features to better understand how well they work. Boost can help the C++ community gain valuable experience with these features by upgrading and extending existing Boost libraries with these new language features. To support this goal, I have committed a set of changes to the Boost config library (on CVS HEAD), which add several new macros to indicate the availability of C++0x features. The list involves only features that I know have been implemented; see below for the compilers that support various features. The new configuration macros are: BOOST_CXX0X_LONG_LONG: long long support (aliases BOOST_HAS_LONG_LONG) BOOST_CXX0X_PREPROCESSOR: C99 preprocessor extensions BOOST_CXX0X_RVALUE_REFERENCES: rvalue references BOOST_CXX0X_STATIC_ASSERT: static assertions BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) BOOST_CXX0X_VARIADIC_TEMPLATES: variadic templates (not yet accepted) This list will grow as more C++0x features become available in compilers. Still, we can now use these macros within Boost libraries however we want. For example, I added the following to boost/static_assert.hpp: #ifdef BOOST_CXX0X_STATIC_ASSERT # define BOOST_STATIC_ASSERT( B ) static_assert(B, #B) #else // today's library-defined BOOST_STATIC_ASSERT #endif The error messages when using a compiler supporting static_assert are much more useful. I know of support for the following C++0x features in publicly available compilers: Rvalue references: - Metrowerks CodeWarrior 10: no link; the compiler was discontinued :( Static assertions: - GCC 4.3.0: http://gcc.gnu.org/gcc-4.3/changes.html (in active development) Concepts: - ConceptGCC: http://www.generic-programming.org/software/ConceptGCC/ Variadic templates: - Patch against GCC: http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html I plan to start nightly Boost regression tests for some of these compilers, so we can track our progress on C++0x support. We get to play with cool new language features *and* help the C++ community at large. What could be better than that? Cheers, Doug
On Nov 22, 2006, at 11:37 AM, Douglas Gregor wrote:
To support this goal, I have committed a set of changes to the Boost config library (on CVS HEAD), which add several new macros to indicate the availability of C++0x features. The list involves only features that I know have been implemented; see below for the compilers that support various features. The new configuration macros are:
BOOST_CXX0X_LONG_LONG: long long support (aliases BOOST_HAS_LONG_LONG) BOOST_CXX0X_PREPROCESSOR: C99 preprocessor extensions BOOST_CXX0X_RVALUE_REFERENCES: rvalue references BOOST_CXX0X_STATIC_ASSERT: static assertions BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) BOOST_CXX0X_VARIADIC_TEMPLATES: variadic templates (not yet accepted)
Thanks Doug. I'm now looking at the boost config library in a whole new light. It doesn't have to be just for configuring boost libraries. I can well imagine I might want to use the boost configure library (even if I didn't want to use any other boost library) to configure *my own* code. -Howard
...
BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) ...
This is slightly off-topic but it does bring up something that has been bothersome to me for some time. Suppose that I had a library which used the new concepts. Then I wrote a few tests to demonstrate the usage of and verify the specification of of the concepts. Then I add the tests to the Jamfile. Now I have a bunch of tests run on all compilers many of which don't support the new concepts. In an attempt to make the testing faster and more useful, I tweak the Jamfile so that these tests are run only with the compilers for which such tests are useful. That doesn't work very well as the test tools name vary quite a lot. gcc, mingw, ... etc What I need is a connection between the config tests and a particular set of tests - something like if "test for presense of new concepts passes" then "run these tests" Maybe this is in the new v2 somewhere. Robert Ramey
Robert Ramey wrote:
Maybe this is in the new v2 somewhere.
Does adding: <dependency>target-name To the test's requirements do it? See http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/bbv2/tasks.h... John.
I saw this and that's what I was referring to. But I'm not sure whether or not it does it. Here is another case from the serialization library. Some compilers don't support wide characters and I would to detect this automatically rather than chasing down all the tool sets on a continuing basis. So the first thought would be to create test in config like: test_wide_char_support which would fail if the proper define isn't set. then the tests which would depend on such support would be invoked conditionally upon the SUCCESSFUL completion of test_wide_char support. This is analogous to the makefile behavior in that a program isn't linked if compilation of any one of its components fails. (I realise that the true dependency is on the existence of an updated *.o file - but the result is the same. As I read the link below - it doesn't seem to help here. Robert Ramey John Maddock wrote:
Robert Ramey wrote:
Maybe this is in the new v2 somewhere.
Does adding:
<dependency>target-name
To the test's requirements do it?
See http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/bbv2/tasks.h...
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I saw this and that's what I was referring to. But I'm not sure whether or not it does it.
Here is another case from the serialization library.
Some compilers don't support wide characters and I would to detect this automatically rather than chasing down all the tool sets on a continuing basis.
So the first thought would be to create test in config like:
test_wide_char_support which would fail if the proper define isn't set.
then the tests which would depend on such support would be invoked conditionally upon the SUCCESSFUL completion of test_wide_char support. This is analogous to the makefile behavior in that a program isn't linked if compilation of any one of its components fails. (I realise that the true dependency is on the existence of an updated *.o file - but the result is the same.
As I read the link below - it doesn't seem to help here.
Yep, the docs didn't seem all that clear to me :-( BTW the wide character test already exists, all the Boost.Config tests have individual tests in libs/config/test as well as the consolidated tests used in the reports. Take a look at the libs/config/configure script to see how these are used in this context. So... maybe just try it and see? Or else nag Vladimir :-) John.
John Maddock wrote:
Robert Ramey wrote:
I saw this and that's what I was referring to. But I'm not sure whether or not it does it.
Here is another case from the serialization library.
Some compilers don't support wide characters and I would to detect this automatically rather than chasing down all the tool sets on a continuing basis.
So the first thought would be to create test in config like:
test_wide_char_support which would fail if the proper define isn't set.
then the tests which would depend on such support would be invoked conditionally upon the SUCCESSFUL completion of test_wide_char support. This is analogous to the makefile behavior in that a program isn't linked if compilation of any one of its components fails. (I realise that the true dependency is on the existence of an updated *.o file - but the result is the same.
As I read the link below - it doesn't seem to help here.
Yep, the docs didn't seem all that clear to me :-(
BTW the wide character test already exists, all the Boost.Config tests have individual tests in libs/config/test as well as the consolidated tests used in the reports. Take a look at the libs/config/configure script to see how these are used in this context.
So... maybe just try it and see? Or else nag Vladimir :-)
I was thinking about some configure checks for Boost.Build just today. I think that at the minimum, something like this (untested!) should work: compile test_that_compiler_is_good_and_shiny.cpp ; unit-test a : a.cpp : <dependency>test_that_compiler_is_good_and_shiny ; If the compile test fails to compile, then 'a' won't be compiled either. We "only" need to make sure that the first test is not added to regression results as "fail". - Volodya
Actually that might be enough to handle the wide char issue in my example. To make things nice a clean it would seem that one would need: a) A simple config tests - test_config_wchar_support marked compile passed b) markup set so that "sometimes fails" so its not marked red c) <dependency>test_config_wchar_support Which would help a lot. There would still be an issue tests don't fail untl runtime. I don't know if that would be required. actually I was sort of expecting (hoping) something like <dependency>test_?.run // dependent on successful exectution of test_? which would be a more general and (to me) natural solution. Robert Ramey
compile test_that_compiler_is_good_and_shiny.cpp ;
unit-test a : a.cpp : <dependency>test_that_compiler_is_good_and_shiny ;
If the compile test fails to compile, then 'a' won't be compiled either. We "only" need to make sure that the first test is not added to regression results as "fail".
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Actually that might be enough to handle the wide char issue in my example.
To make things nice a clean it would seem that one would need:
a) A simple config tests - test_config_wchar_support marked compile passed b) markup set so that "sometimes fails" so its not marked red c) <dependency>test_config_wchar_support
Which would help a lot.
Well (c) is in place, (a) can be easily written if you know what to test and (b) is the only missing bit.
There would still be an issue tests don't fail untl runtime. I don't know if that would be required.
actually I was sort of expecting (hoping) something like
<dependency>test_?.run // dependent on successful exectution of test_?
run foo_present.cpp ; run a.cpp : : : <dependency>foo_present ; happens to work as expected as of 2 mins ago. - Volodya
Robert Ramey wrote:
...
BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) ...
This is slightly off-topic but it does bring up something that has been bothersome to me for some time.
Suppose that I had a library which used the new concepts. Then I wrote a few tests to demonstrate the usage of and verify the specification of of the concepts. Then I add the tests to the Jamfile. Now I have a bunch of tests run on all compilers many of which don't support the new concepts. In an attempt to make the testing faster and more useful, I tweak the Jamfile so that these tests are run only with the compilers for which such tests are useful. That doesn't work very well as the test tools name vary quite a lot. gcc, mingw, ... etc
What I need is a connection between the config tests and a particular set of tests - something like
How about this idea: * we reserve a specific error code for indicating "not supported on this platform". * your test code diverts to int main() { return BOOST_PLATFORM_NOT_SUPPORTED; } for unsupported platforms * the postprocessing chain gets adjusted to deal with that specific result. If using an exit code is not viable then we also could do something along this: int main() { std::cout << "<platform_unsupported/>\n"; return EXIT_FAILURE; } Or static_assert(platform_unupported) or even #error "<platform_unsupported/>" I think this would simplify managing expected failures a lot (no specific markup needed) and it would also reduce the cost of needlessly compiling and running tests that will fail. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille wrote:
If using an exit code is not viable then we also could do something along this: int main() { std::cout << "<platform_unsupported/>\n"; return EXIT_FAILURE; }
Or static_assert(platform_unupported) or even #error "<platform_unsupported/>"
The trouble is these aren't traditional configure tests, what we really want is "Does this compile, link and run? Yes: OK we have the feature, No: it's not usable." So we can't fix the errors in advance :-( John.
John Maddock wrote:
Martin Wille wrote:
If using an exit code is not viable then we also could do something along this: int main() { std::cout << "<platform_unsupported/>\n"; return EXIT_FAILURE; }
Or static_assert(platform_unupported) or even #error "<platform_unsupported/>"
The trouble is these aren't traditional configure tests, what we really want is "Does this compile, link and run? Yes: OK we have the feature, No: it's not usable." So we can't fix the errors in advance :-(
IIUC, Robert was concerned about managing tests that are only supported by a subset of the compilers. He wasn't directly talking about how Boost.Config should handle things. (Obviously, Boost.Config should not immediately #error for missing support of concept checking.) I know that my suggestion doesn't offer a perfect solution. However, it addresses the most pressing problems rather effectively: explosion of manual markups (by adding markup to the tests), explosion of exclusion management in the build system (by shortcutting compilation/execution), and compile/runtime costs for testing what is to known fail (also by shortcutting). These are the problems Robert wanted to avoid, IIUC. We went the #error route for the Spirit tests and it helped a lot (back when I was running gcc 2 tests). Adding markup to the output from the compiler and/or from the test run would also allow for inserting comments into the result tables without having to fiddle with the manual markup file. I think this could be interesting, too. Version management becomes easier, too, since the markup and the code the markup is referring to are the the same file and share the same CVS history. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
On Wed, 2006-11-22 at 19:30 +0100, Mathias Gaunard wrote:
Douglas Gregor wrote:
Rvalue references: - Metrowerks CodeWarrior 10: no link; the compiler was discontinued :(
Does anyone know about the status of a patch to add this to GCC ?
We've been in contact with the original author of the patch, and I know of at least one other person who has studied rvalues references and their implementation in GCC. We're working on it; I'm feeling pretty confident that we'll get rvalue references for GCC in the near future. Cheers, Doug
Mathias Gaunard escreveu:
Douglas Gregor wrote:
Rvalue references: - Metrowerks CodeWarrior 10: no link; the compiler was discontinued :(
Does anyone know about the status of a patch to add this to GCC ?
There is a patch, which last time I checked was not complete, here: http://russ.yanofsky.org/rref/ I have some work of my own lying around somewhere; I'm working on resurrecting it right now. -- Pedro Lamarão
Douglas Gregor wrote:
To support this goal, I have committed a set of changes to the Boost config library (on CVS HEAD), which add several new macros to indicate the availability of C++0x features. The list involves only features that I know have been implemented; see below for the compilers that support various features. The new configuration macros are:
BOOST_CXX0X_LONG_LONG: long long support (aliases BOOST_HAS_LONG_LONG) BOOST_CXX0X_PREPROCESSOR: C99 preprocessor extensions BOOST_CXX0X_RVALUE_REFERENCES: rvalue references BOOST_CXX0X_STATIC_ASSERT: static assertions BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) BOOST_CXX0X_VARIADIC_TEMPLATES: variadic templates (not yet accepted)
Should these be positive or negative feature tests? I am imagining that once tests for these features are in place, library maintainers will not want to revisit code once C++0x is published to test for BOOST_NO_VARIADIC_TEMPLATES instead. The latter form is more typical of how we deal with feature-detection today. As library maintainer John Maddoc should get the final call, but my preference would be BOOST_NO_FEATURE forms. It should be fairly easy to create a single header that all compiler configs can use, and then selectively undef features in the compiler config file itself as new features are implemented.
This list will grow as more C++0x features become available in compilers.
Other features I am aware of: I believe MSVC implements delegating constructors, although that may be only in C++/CLI mode. Likewise, I am not sure about nullptr. I believe Borland implement C99 preprocessor extensions in their C++ compiler. Suspect several others do too. and of course, most compilers implement long long now. -- AlisdairM
AlisdairM wrote:
Douglas Gregor wrote:
To support this goal, I have committed a set of changes to the Boost config library (on CVS HEAD), which add several new macros to indicate the availability of C++0x features. The list involves only features that I know have been implemented; see below for the compilers that support various features. The new configuration macros are:
BOOST_CXX0X_LONG_LONG: long long support (aliases BOOST_HAS_LONG_LONG) BOOST_CXX0X_PREPROCESSOR: C99 preprocessor extensions BOOST_CXX0X_RVALUE_REFERENCES: rvalue references BOOST_CXX0X_STATIC_ASSERT: static assertions BOOST_CXX0X_CONCEPTS: concepts (not yet accepted) BOOST_CXX0X_VARIADIC_TEMPLATES: variadic templates (not yet accepted)
Should these be positive or negative feature tests? I am imagining that once tests for these features are in place, library maintainers will not want to revisit code once C++0x is published to test for BOOST_NO_VARIADIC_TEMPLATES instead. The latter form is more typical of how we deal with feature-detection today.
As library maintainer John Maddoc should get the final call, but my preference would be BOOST_NO_FEATURE forms. It should be fairly easy to create a single header that all compiler configs can use, and then selectively undef features in the compiler config file itself as new features are implemented.
It's a tricky one this: normally we would use BOOST_HAS_WHATEVER since these features aren't std yet, however as you say, they will be soon. So I could go either way. The names should probably be either BOOST_HAS_WHATEVER or BOOST_NO_WHATEVER though so it's clear what we're talking about! John.
On Thu, 2006-11-23 at 09:34 +0000, John Maddock wrote:
As library maintainer John Maddoc should get the final call, but my preference would be BOOST_NO_FEATURE forms. It should be fairly easy to create a single header that all compiler configs can use, and then selectively undef features in the compiler config file itself as new features are implemented.
It's a tricky one this: normally we would use BOOST_HAS_WHATEVER since these features aren't std yet, however as you say, they will be soon. So I could go either way. The names should probably be either BOOST_HAS_WHATEVER or BOOST_NO_WHATEVER though so it's clear what we're talking about!
I created the new category BOOST_CXX0X_* to avoid the question entirely :) I really don't like BOOST_HAS_*, because that's only for optional features. C++0x isn't optional; it's a different standard. Alisdair's idea of using BOOST_NO_* (with a big #define header, followed by undefs for compilers) is intruiging... I'd be okay with that. I'll do whatever John asks :) Cheers, Doug
Douglas Gregor wrote:
I created the new category BOOST_CXX0X_* to avoid the question entirely :)
Understood.
I really don't like BOOST_HAS_*, because that's only for optional features. C++0x isn't optional; it's a different standard.
Except it's not a final std yet?
Alisdair's idea of using BOOST_NO_* (with a big #define header, followed by undefs for compilers) is intruiging... I'd be okay with that.
I'll do whatever John asks :)
Oooo, power :-) OK there are a couple of outstanding issues: * We need test cases for the new macros. * The config-tools (the configure script and the small generator program under libs/config/tools that updates the test driver and config_test.cpp+config_info.cpp) assume that the macros are named BOOST_NO_* or BOOST_HAS_HAS_*, without that they don't work :-( The general proceedure for new macros is documented here: http://www.boost.org/libs/config/config.htm#defect_guidelines So could you either use BOOST_HAS_* or else modify the configure.in script and the generate.cpp program to do the right thing? Many thanks, John.
John Maddock wrote:
OK there are a couple of outstanding issues:
* We need test cases for the new macros. * The config-tools (the configure script and the small generator program under libs/config/tools that updates the test driver and config_test.cpp+config_info.cpp) assume that the macros are named BOOST_NO_* or BOOST_HAS_HAS_*, without that they don't work :-(
The general proceedure for new macros is documented here: http://www.boost.org/libs/config/config.htm#defect_guidelines
So could you either use BOOST_HAS_* or else modify the configure.in script and the generate.cpp program to do the right thing?
Belay that: as long as the *test case names* are named boost_has*.ipp then everything should "just work" whatever the macro names. So I don't really mind what you call them, BOOST_CXX0X* is fine by me then :-) John.
participants (9)
-
AlisdairM -
Douglas Gregor -
Howard Hinnant -
John Maddock -
Martin Wille -
Mathias Gaunard -
Pedro Lamarão -
Robert Ramey -
Vladimir Prus