[Boost] [Config] Macros for the absence of a full C++11 <memory> implementation
Macros to determine the availability of C++11 functions in <memory> like std::align would be useful to me. (I know that declaration begs the inquiry "What conforming code would you write if std::align is not present?" but that is separate e-mail...) Would a BOOST_NO_CXX11_HDR_MEMORY be generally useful? Glen
Macros to determine the availability of C++11 functions in <memory> like std::align would be useful to me.
(I know that declaration begs the inquiry "What conforming code would you write if std::align is not present?" but that is separate e-mail...)
Would a BOOST_NO_CXX11_HDR_MEMORY be generally useful?
Perhaps, we currently have <memory> broken up into chunks for config-testing as a lot of non-connected things were added for C++11: BOOST_NO_CXX11_ALLOCATOR BOOST_NO_CXX11_ATOMIC_SMART_PTR BOOST_NO_CXX11_SMART_PTR But as you've noticed, those don't cover the whole thing. So I guess the question is do you really want a macro for a *fully* conforming <memory> or another test for a new subset? John.
Perhaps, we currently have <memory> broken up into chunks for config-testing as a lot of non-connected things were added for C++11:
BOOST_NO_CXX11_ALLOCATOR BOOST_NO_CXX11_ATOMIC_SMART_PTR BOOST_NO_CXX11_SMART_PTR
But as you've noticed, those don't cover the whole thing. So I guess the question is do you really want a macro for a *fully* conforming <memory> or another test for a new subset?
The latter is preferable; e.g. BOOST_NO_CXX11_ALIGN (or a more appropriate identifier) indicating the absence of std::align. It just felt a little wrong to desire a macro for just one function though. Glen
Glen Fernandes wrote:
Perhaps, we currently have <memory> broken up into chunks for config-testing as a lot of non-connected things were added for C++11:
BOOST_NO_CXX11_ALLOCATOR BOOST_NO_CXX11_ATOMIC_SMART_PTR BOOST_NO_CXX11_SMART_PTR
But as you've noticed, those don't cover the whole thing. So I guess the question is do you really want a macro for a *fully* conforming <memory> or another test for a new subset?
The latter is preferable; e.g. BOOST_NO_CXX11_ALIGN (or a more appropriate identifier) indicating the absence of std::align. It just felt a little wrong to desire a macro for just one function though.
The above three macros, plus the additional BOOST_NO_CXX11_STD_ALIGN, would cover the whole C++11 <memory> except for the reachability functions (which nobody needs)... and std::addressof, which is pretty useful. Perhaps we need to add BOOST_NO_CXX11_ADDRESSOF while we're at it.
From: lists@pdimov.com To: boost@lists.boost.org Date: Tue, 11 Feb 2014 03:46:25 +0200 Subject: Re: [boost] [Boost] [Config] Macros for the absence of a full C++11 <memory> implementation
The above three macros, plus the additional BOOST_NO_CXX11_STD_ALIGN, would cover the whole C++11 <memory> except for the reachability functions (which nobody needs)... and std::addressof, which is pretty useful. Perhaps we need to add BOOST_NO_CXX11_ADDRESSOF while we're at it.
Boost has boost::addressof, which does the same thing as the standard one, so there probably isn't much reason to detect the standard one.
The latter is preferable; e.g. BOOST_NO_CXX11_ALIGN (or a more appropriate identifier) indicating the absence of std::align. It just felt a little wrong to desire a macro for just one function though.
The above three macros, plus the additional BOOST_NO_CXX11_STD_ALIGN, would cover the whole C++11 <memory> except for the reachability functions (which nobody needs)... and std::addressof, which is pretty useful. Perhaps we need to add BOOST_NO_CXX11_ADDRESSOF while we're at it.
Would somebody like to produce a patch? John.
John Maddock wrote:
Would somebody like to produce a patch?
I'm trying to but have hit a snag. I have this as boost_no_cxx11_addressof.ipp: #include <memory> namespace boost_no_cxx11_addressof { void x3() { } int test() { int x1, x2[3]; return std::addressof(x1) != &x1 || std::addressof(x2) != &x2 || std::addressof(x3) != &x3; } } That is, I am not just testing whether std::addressof compiles, I'm also testing if it actually works. This is a problem because the expectation for this file is to fail compilation when the macro ought to be set. However, it sometimes fails compilation (when std::addressof is not present at all), and sometimes fails at runtime (when std::addressof is present but doesn't pass the test, as in VC++12). And we don't have a rule for that. compile-fail always wants it to fail compilation; run-fail always wants it to compile/link and only then fail. I don't know how one can express "this test should fail at compile time or at run time" in Boost.Build.
Peter Dimov wrote:
Apart from that, I prepared the patch and submitted a pull request.
We should actually define BOOST_NO_CXX11_STD_ALIGN for Dinkumware version 540. Though it provides std::align in <memory> it is a non-conforming implementation; i.e. it adjusts the pointer correctly but it does not return the correct address. Dinkumware version 610 has it implemented correctly. Glen
We should actually define BOOST_NO_CXX11_STD_ALIGN for Dinkumware version 540. Though it provides std::align in <memory> it is a non-conforming implementation; i.e. it adjusts the pointer correctly but it does not return the correct address. Dinkumware version 610 has it implemented correctly.
I merged your pull-request - many thanks for checking that, John.
This is a problem because the expectation for this file is to fail compilation when the macro ought to be set. However, it sometimes fails compilation (when std::addressof is not present at all), and sometimes fails at runtime (when std::addressof is present but doesn't pass the test, as in VC++12).
And we don't have a rule for that. compile-fail always wants it to fail compilation; run-fail always wants it to compile/link and only then fail. I don't know how one can express "this test should fail at compile time or at run time" in Boost.Build.
No there are several tests that don't work quite right because there's no opposite to "run" in Boost.Build. Note that config_test.cpp will check runtime as well as compile time fails: it's only the "full" tests which may not quite do the right thing (these aren't run as part of the regression test suite - there mostly there as a sanity check to see which macros *might* be unset in a new compiler edition). John.
AMDG On 02/11/2014 08:59 AM, John Maddock wrote:
This is a problem because the expectation for this file is to fail compilation when the macro ought to be set. However, it sometimes fails compilation (when std::addressof is not present at all), and sometimes fails at runtime (when std::addressof is present but doesn't pass the test, as in VC++12).
And we don't have a rule for that. compile-fail always wants it to fail compilation; run-fail always wants it to compile/link and only then fail. I don't know how one can express "this test should fail at compile time or at run time" in Boost.Build.
No there are several tests that don't work quite right because there's no opposite to "run" in Boost.Build.
I'd be happy to implement such a rule if anyone can figure out how to represent it in the dependency graph. What we have for run-fail looks somethings like this: DEPENDS x.obj : x.cpp ; msvc.compile.c++ x.obj : x.cpp ; DEPENDS x.exe : x.obj ; msvc.link x.exe : x.obj ; DEPENDS x.run : x.exe ; testing.capture-output : x.run : x.exe ; FAIL_EXPECTED x.run ; What we would need is a way to say that we expect x.obj OR x.exe OR x.run to fail. We could say that x.run passes iff testing.capture-output is skipped because a dependency failed or has non-zero exit status. But... this will make a mess of the total pass/fail counts and will fail badly with -q, not to mention that it will cause the test to pass if a library dependency fails to build. In Christ, Steven Watanabe
We could say that x.run passes iff testing.capture-output is skipped because a dependency failed or has non-zero exit status. But... this will make a mess of the total pass/fail counts and will fail badly with -q, not to mention that it will cause the test to pass if a library dependency fails to build.
I realise this may not be possible, but a better rule would be a "not" rule: passes only if it's dependency failed. But like you say, the total pass/fail count would presumably be messed up? John.
AMDG On 02/17/2014 01:48 AM, John Maddock wrote:
We could say that x.run passes iff testing.capture-output is skipped because a dependency failed or has non-zero exit status. But... this will make a mess of the total pass/fail counts and will fail badly with -q, not to mention that it will cause the test to pass if a library dependency fails to build.
I realise this may not be possible, but a better rule would be a "not" rule: passes only if it's dependency failed. But like you say, the total pass/fail count would presumably be messed up?
That's annoying, but not really important. Handling -q (stop on error) is much more of a problem. Actually, there is a way to handle this. Unfortunately, it requires intrusive changes to the toolsets. compile.c++ x.obj x.run : x.cpp ; link x.exe x.run : x.obj ; capture-output x.run : x.exe ; FAIL_EXPECTED x.run ; NOCARE x.obj x.exe ; By using x.run in all three rules, we cause x.run to fail immediately when any of these rules fails. FAIL_EXPECTED then flips the final status to pass. Since x.obj and x.exe might succeed or fail, we also say that it doesn't matter whether they update successfully. (Note that this will only work correctly with a recent b2. I think I fixed some problems when using FAIL_EXPECTED with multiple updating actions a few months ago) In Christ, Steven Watanabe
participants (5)
-
Ahmed Charles -
Glen Fernandes -
John Maddock -
Peter Dimov -
Steven Watanabe