[Config] Meaning of BOOST_NO_CXX11_HDR_INITIALIZER_LIST
I noticed that BOOST_NO_INITIALIZER_LISTS was replaced by BOOST_NO_CXX11_HDR_INITIALIZER_LIST recently. I have a question related to this change: Does BOOST_NO_CXX11_HDR_INITIALIZER_LIST imply that initializer lists are supported by the compiler? (I guess that the compiler support is checked in a compiler config and the existence of <initializer_list> is checked in a std lib config.) If so, shouldn't the documentation be updated? Regards, Michel
I noticed that BOOST_NO_INITIALIZER_LISTS was replaced by BOOST_NO_CXX11_HDR_INITIALIZER_LIST recently. I have a question related to this change: Does BOOST_NO_CXX11_HDR_INITIALIZER_LIST imply that initializer lists are supported by the compiler? (I guess that the compiler support is checked in a compiler config and the existence of <initializer_list> is checked in a std lib config.)
If so, shouldn't the documentation be updated?
I believe the intent of the change is that the header and the compiler feature are unusable without each other, so only one macro is enough. Marshall? John.
On Mar 7, 2012, at 10:12 AM, John Maddock wrote:
I noticed that BOOST_NO_INITIALIZER_LISTS was replaced by BOOST_NO_CXX11_HDR_INITIALIZER_LIST recently. I have a question related to this change: Does BOOST_NO_CXX11_HDR_INITIALIZER_LIST imply that initializer lists are supported by the compiler? (I guess that the compiler support is checked in a compiler config and the existence of <initializer_list> is checked in a std lib config.)
If so, shouldn't the documentation be updated?
I believe the intent of the change is that the header and the compiler feature are unusable without each other, so only one macro is enough.
That's the intent, yes. One version of MSVC shipped with a header, but no support, IIRC - but MS said that was their mistake. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
[Marshall Clow]
One version of MSVC shipped with a header, but no support, IIRC - but MS said that was their mistake.
Yeah, my mistake - I thought we'd removed all traces of initializer list support from VC10 (there's no sense in shipping preprocessor-dead code that's just going to confuse users), but I just plain forgot about the header itself. I removed it from VC11 early on. STL
Thanks all! Then, we need to update the documentation. I was trying to make a patch, but .qbk file does not seem to be up-to-date... P.S. I think it would be better to deprecate BOOST_NO_STD_UNORDERED, too. The stdlib config files have the following code # define BOOST_NO_STD_UNORDERED // deprecated; see following # define BOOST_NO_CXX11_HDR_UNORDERED_MAP # define BOOST_NO_CXX11_HDR_UNORDERED_SET So it's time to remove BOOST_NO_STD_UNORDERED from the documentation (and move the implementation to suffix.hpp)! Regards, Michel
On Mar 7, 2012, at 7:25 PM, Michel Morin wrote:
Thanks all!
Then, we need to update the documentation. I was trying to make a patch, but .qbk file does not seem to be up-to-date...
P.S. I think it would be better to deprecate BOOST_NO_STD_UNORDERED, too. The stdlib config files have the following code
# define BOOST_NO_STD_UNORDERED // deprecated; see following # define BOOST_NO_CXX11_HDR_UNORDERED_MAP # define BOOST_NO_CXX11_HDR_UNORDERED_SET
So it's time to remove BOOST_NO_STD_UNORDERED from the documentation (and move the implementation to suffix.hpp)!
Now there's a hoot. I just finished searching for BOOST_NO_STD_UNORDERED to see if anyone in boost was using it - with the same idea. In all the cases that I've looked at, if BOOST_NO_STD_UNORDERED is set, so are BOOST_NO_CXX11_HDR_UNORDERED_MAP and BOOST_NO_CXX11_HDR_UNORDERED_SET However, there are cases where BOOST_NO_STD_UNORDERED is _not_ set, and the other ones are. [ I think those might be bugs. ] We could just say that BOOST_NO_CXX11_HDR_UNORDERED_SET is a synonym for BOOST_NO_STD_UNORDERED, and is the preferred replacement. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Now there's a hoot. I just finished searching for BOOST_NO_STD_UNORDERED to see if anyone in boost was using it - with the same idea.
In all the cases that I've looked at, if BOOST_NO_STD_UNORDERED is set, so are BOOST_NO_CXX11_HDR_UNORDERED_MAP and BOOST_NO_CXX11_HDR_UNORDERED_SET
However, there are cases where BOOST_NO_STD_UNORDERED is _not_ set, and the other ones are. [ I think those might be bugs. ]
We could just say that BOOST_NO_CXX11_HDR_UNORDERED_SET is a synonym for BOOST_NO_STD_UNORDERED, and is the preferred replacement.
Agreed we should deprecate BOOST_NO_STD_UNORDERED - but I would set it if *either* of BOOST_NO_CXX11_HDR_UNORDERED_SET or BOOST_NO_CXX11_HDR_UNORDERED_MAP is set (since it implies both). John.
On Mar 8, 2012, at 2:15 AM, John Maddock wrote:
Now there's a hoot. I just finished searching for BOOST_NO_STD_UNORDERED to see if anyone in boost was using it - with the same idea.
In all the cases that I've looked at, if BOOST_NO_STD_UNORDERED is set, so are BOOST_NO_CXX11_HDR_UNORDERED_MAP and BOOST_NO_CXX11_HDR_UNORDERED_SET
However, there are cases where BOOST_NO_STD_UNORDERED is _not_ set, and the other ones are. [ I think those might be bugs. ]
We could just say that BOOST_NO_CXX11_HDR_UNORDERED_SET is a synonym for BOOST_NO_STD_UNORDERED, and is the preferred replacement.
Agreed we should deprecate BOOST_NO_STD_UNORDERED - but I would set it if *either* of BOOST_NO_CXX11_HDR_UNORDERED_SET or BOOST_NO_CXX11_HDR_UNORDERED_MAP is set (since it implies both).
John -- There's some serious weirdnesses in the logic of defining BOOST_NO_STD_UNORDERED; can you take a look at the STLPort configuration and let me know what you think should be done there? Also, is there/should there be a relationship between BOOST_NO_STD_UNORDERED and BOOST_HAS_TR1_HDR_UNORDERED_MAP/SET? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
There's some serious weirdnesses in the logic of defining BOOST_NO_STD_UNORDERED; can you take a look at the STLPort configuration and let me know what you think should be done there?
Shucks, not sure :-( My suspicion is that STLport had std::unordered_* for a while (inherited from the old SGI STL), then moved them into std::tr1:: and now back to std:: again. Of course the early versions probably aren't completely compatible with what ended up in the std either :-( I guess just remove the code that sets BOOST_NO_STD_UNORDERED here, and stick with the original plan, if that breaks obsolete STLport versions then too bad I guess....?
Also, is there/should there be a relationship between BOOST_NO_STD_UNORDERED and BOOST_HAS_TR1_HDR_UNORDERED_MAP/SET?
Not quite as the former relates to what's in std:: and the latter std::tr1:: HTH, John.
On Mar 8, 2012, at 10:32 AM, John Maddock wrote:
There's some serious weirdnesses in the logic of defining BOOST_NO_STD_UNORDERED; can you take a look at the STLPort configuration and let me know what you think should be done there?
Shucks, not sure :-(
My suspicion is that STLport had std::unordered_* for a while (inherited from the old SGI STL), then moved them into std::tr1:: and now back to std:: again.
Of course the early versions probably aren't completely compatible with what ended up in the std either :-(
I guess just remove the code that sets BOOST_NO_STD_UNORDERED here, and stick with the original plan, if that breaks obsolete STLport versions then too bad I guess….?
Done. Revision r77274 BOOST_NO_STD_UNORDERED is defined if either BOOST_NO_CXX11_HDR_UNORDERED_SET or BOOST_NO_CXX11_HDR_UNORDERED_MAP is set John, there's a test that depends on gcc 3.1 that I'd appreciate you taking a look at. libs/config/test/boost_has_hash.ipp -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
John, there's a test that depends on gcc 3.1 that I'd appreciate you taking a look at. libs/config/test/boost_has_hash.ipp
I don't think there's a need to change anything there is there? The logic is just saying that we can't include both <ext/hash_set> and <hash_set>, so as long as BOOST_NO_STD_UNORDERED gets set in suffix.hpp I think it should be OK? Hopefully ;-) John.
On Mar 8, 2012, at 11:07 AM, John Maddock wrote:
John, there's a test that depends on gcc 3.1 that I'd appreciate you taking a look at. libs/config/test/boost_has_hash.ipp
I don't think there's a need to change anything there is there? The logic is just saying that we can't include both <ext/hash_set> and <hash_set>, so as long as BOOST_NO_STD_UNORDERED gets set in suffix.hpp I think it should be OK? Hopefully ;-)
Well, I'd like to change it to use something else (some other macro) instead, since we're deprecating BOOST_NO_STD_UNORDERED, and I was wondering which one you thought was most appropriate. Apologies for not making that clear. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
I don't think there's a need to change anything there is there? The logic is just saying that we can't include both <ext/hash_set> and <hash_set>, so as long as BOOST_NO_STD_UNORDERED gets set in suffix.hpp I think it should be OK? Hopefully ;-)
Well, I'd like to change it to use something else (some other macro) instead, since we're deprecating BOOST_NO_STD_UNORDERED, and I was wondering which one you thought was most appropriate.
OK, the strict replacement would be to replace: defined(BOOST_NO_STD_UNORDERED) with (defined(BOOST_NO_CXX11_HDR_UNORDERED_MAP) || defined(BOOST_NO_CXX11_HDR_UNORDERED_SET)) since including either of those headers would break the test. HTH, John.
Michel Morin wrote:
I was trying to make a patch, but .qbk file does not seem to be up-to-date...
John, what is the workflow for updating Boost.Config documentation? Is the following workflow correct? 1. Update quickbook files. 2. Regenerate HTML files. 3. Commit them. Marshall, could you update macro_reference.qbk for r77194? Thanks, Michel
On Mar 8, 2012, at 7:00 AM, Michel Morin wrote:
Michel Morin wrote:
I was trying to make a patch, but .qbk file does not seem to be up-to-date...
John, what is the workflow for updating Boost.Config documentation? Is the following workflow correct?
1. Update quickbook files. 2. Regenerate HTML files. 3. Commit them.
Marshall, could you update macro_reference.qbk for r77194?
Done in r77264 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Let's go back again to the BOOST_NO_CXX11_HDR_INITIALIZER_LIST discussion. I believe that BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX checks the compiler support of initializer_list as well. So better implementation of BOOST_NO_CXX11_HDR_INITIALIZER_LIST would be: 1. In compiler configs, don't define BOOST_NO_CXX11_HDR_INITIALIZER_LIST. 2. In stdlib configs, define BOOST_NO_CXX11_HDR_INITIALIZER_LIST if stdlib doesn't have <initializer_list>. 3. In suffix.hpp, define BOOST_NO_CXX11_HDR_INITIALIZER_LIST if BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX is defined (and BOOST_NO_CXX11_HDR_INITIALIZER_LIST is not defined): #if defined(BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX) && !defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) # define BOOST_NO_CXX11_HDR_INITIALIZER_LIST #endif I also came up with another thoughts. Do we really want BOOST_NO_CXX11_HDR_INITIALIZER_LIST to check the compiler support of initializer_list? Even if BOOST_NO_CXX11_HDR_INITIALIZER_LIST checks only the existence of <initializer_list>, we can check both the compiler support and the header existence by defined(BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX) || defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) Comments? Regards, Michel
participants (4)
-
John Maddock -
Marshall Clow -
Michel Morin -
Stephan T. Lavavej