[config] Deprecate/remove BOOST_NO_INITIALIZER_LISTS
Hi, Once BOOST_NO_0X_HDR_INITIALIZER_LIST has been added to release, I think we should remove BOOST_NO_INITIALIZER_LISTS. It's confusing having both macros. BOOST_NO_INITIALIZER_LISTS is probably useless as it only indicates compiler support and initializer lists can't really be used without the header. I seem to be the only person who uses it, so it might be okay to just remove it immediately or if not, deprecate it and remove it in the next release. Does that sound okay? Daniel
Once BOOST_NO_0X_HDR_INITIALIZER_LIST has been added to release, I think we should remove BOOST_NO_INITIALIZER_LISTS. It's confusing having both macros. BOOST_NO_INITIALIZER_LISTS is probably useless as it only indicates compiler support and initializer lists can't really be used without the header. I seem to be the only person who uses it, so it might be okay to just remove it immediately or if not, deprecate it and remove it in the next release. Does that sound okay?
If a grep confirms that no one else is using it: then yes please do remove it altogether. Thanks, John.
On Tue, May 26, 2009 at 6:16 PM, Daniel James <daniel_james@fmail.co.uk>wrote:
Hi,
Once BOOST_NO_0X_HDR_INITIALIZER_LIST has been added to release, I think we should remove BOOST_NO_INITIALIZER_LISTS. It's confusing having both macros. BOOST_NO_INITIALIZER_LISTS is probably useless as it only indicates compiler support and initializer lists can't really be used without the header. I seem to be the only person who uses it, so it might be okay to just remove it immediately or if not, deprecate it and remove it in the next release. Does that sound okay?
Does it matter that some standard libraries might add <initializer_list> even though the compiler doesn't have support yet? --Beman
2009/5/28 Beman Dawes <bdawes@acm.org>:
Does it matter that some standard libraries might add <initializer_list> even though the compiler doesn't have support yet?
That's already the case for g++ 4.4 when not compiling in c++0x mode. The contents are protected by a macro check but there's no warning or error. I'd hope that BOOST_NO_0X_HDR_INITIALIZER_LIST isn't defined in that case. The header is there but it's entirely useless. Daniel
On Thu, May 28, 2009 at 5:20 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
2009/5/28 Beman Dawes <bdawes@acm.org>:
Does it matter that some standard libraries might add <initializer_list> even though the compiler doesn't have support yet?
That's already the case for g++ 4.4 when not compiling in c++0x mode. The contents are protected by a macro check but there's no warning or error. I'd hope that BOOST_NO_0X_HDR_INITIALIZER_LIST isn't defined in that case. The header is there but it's entirely useless.
Boost.Config for libstdcpp3 is set up to report the C++0x headers as not being present if !defined(__GXX_EXPERIMENTAL_CXX0X__), so we should be OK. Let me know if there are any problems. --Beman
2009/5/29 Beman Dawes <bdawes@acm.org>:
On Thu, May 28, 2009 at 5:20 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
2009/5/28 Beman Dawes <bdawes@acm.org>:
Does it matter that some standard libraries might add <initializer_list> even though the compiler doesn't have support yet?
That's already the case for g++ 4.4 when not compiling in c++0x mode.
Sorry, I was being dense and missed your point. I've had a look at the Visual C++ 10 beta results and that has the situation you describe and BOOST_NO_INITIALIZER_LISTS is required in that case. I went ahead and added a check to config/suffix.hpp to set BOOST_NO_INITIALIZER_LISTS if the headers aren't available: https://svn.boost.org/trac/boost/changeset/53524/trunk Daniel
participants (3)
-
Beman Dawes -
Daniel James -
John Maddock