Playing with the release candidate of MSVC 10, and I'm noticing boost 1.42.0 is not using any C++0x features. Has this been discussed before, or is there a reason for this? Taking a peek at boost/config/compiler/visualc.hpp, I see the following: #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #endif // _MSC_VER < 1600 // C++0x features not supported by any versions #define BOOST_NO_CHAR16_T #define BOOST_NO_CHAR32_T #define BOOST_NO_CONCEPTS #define BOOST_NO_CONSTEXPR #define BOOST_NO_DEFAULTED_FUNCTIONS #define BOOST_NO_DELETED_FUNCTIONS #define BOOST_NO_EXPLICIT_CONVERSION_OPERATORS #define BOOST_NO_EXTERN_TEMPLATE #define BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS #define BOOST_NO_INITIALIZER_LISTS #define BOOST_NO_RAW_LITERALS #define BOOST_NO_SCOPED_ENUMS #define BOOST_NO_SFINAE_EXPR #define BOOST_NO_TEMPLATE_ALIASES #define BOOST_NO_UNICODE_LITERALS #define BOOST_NO_VARIADIC_TEMPLATES It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following? #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #else #define BOOST_HAS_AUTO_DECLARATIONS #define BOOST_HAS_AUTO_MULTIDECLARATIONS #define BOOST_HAS_DECLTYPE #define BOOST_HAS_LAMBDAS #define BOOST_HAS_RVALUE_REFERENCES #define BOOST_HAS_STATIC_ASSERT #define BOOST_HAS_NULLPTR #endif // _MSC_VER < 1600 Zach
On 14 February 2010 22:30, Zachary Turner <divisortheory@gmail.com> wrote:
It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following?
I thought the convention was, for standard features, to just have the _NO_ version, and check for #ifndef if you want it, rather than having to keep both _NO_ and _HAS_ versions of the same thing.
On Sun, Feb 14, 2010 at 9:45 PM, Scott McMurray <me22.ca+boost@gmail.com>wrote:
On 14 February 2010 22:30, Zachary Turner <divisortheory@gmail.com> wrote:
It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following?
I thought the convention was, for standard features, to just have the _NO_ version, and check for #ifndef if you want it, rather than having to keep both _NO_ and _HAS_ versions of the same thing.
Possibly, to be honest I'm not familiar with the conventions surrounding these sorts of things and I couldn't find much documentation. The solution I came up with was based off of looking at the gcc header file, and noting that it does keep _NO_ and _HAS_ versions of the constants, and additionally in various header files I still see plenty of references to BOOST_HAS_xxx scattered around. Either way, I guess some consensus needs to be reached, and maybe we should change the rest of the codebase to follow it so that all libraries agree on the convention.
AMDG Zachary Turner wrote:
On Sun, Feb 14, 2010 at 9:45 PM, Scott McMurray <me22.ca+boost@gmail.com>wrote:
On 14 February 2010 22:30, Zachary Turner <divisortheory@gmail.com> wrote:
It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following?
I thought the convention was, for standard features, to just have the _NO_ version, and check for #ifndef if you want it, rather than having to keep both _NO_ and _HAS_ versions of the same thing.
Possibly, to be honest I'm not familiar with the conventions surrounding these sorts of things and I couldn't find much documentation. The solution I came up with was based off of looking at the gcc header file, and noting that it does keep _NO_ and _HAS_ versions of the constants, and additionally in various header files I still see plenty of references to BOOST_HAS_xxx scattered around.
Either way, I guess some consensus needs to be reached, and maybe we should change the rest of the codebase to follow it so that all libraries agree on the convention.
If I recall correctly... C++0x features were originally, HAS_*, but we decided that it should really be NO_* a while back. The HAS_* versions are still there for backwards compatibility. In Christ, Steven Watanabe
On Sun, Feb 14, 2010 at 10:54 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Zachary Turner wrote:
On Sun, Feb 14, 2010 at 9:45 PM, Scott McMurray <me22.ca+boost@gmail.com
wrote:
On 14 February 2010 22:30, Zachary Turner <divisortheory@gmail.com> wrote:
It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following?
I thought the convention was, for standard features, to just have the _NO_ version, and check for #ifndef if you want it, rather than having to keep both _NO_ and _HAS_ versions of the same thing.
Possibly, to be honest I'm not familiar with the conventions surrounding these sorts of things and I couldn't find much documentation. The solution I came up with was based off of looking at the gcc header file, and noting that it does keep _NO_ and _HAS_ versions of the constants, and additionally in various header files I still see plenty of references to BOOST_HAS_xxx scattered around.
Either way, I guess some consensus needs to be reached, and maybe we should change the rest of the codebase to follow it so that all libraries agree on the convention.
If I recall correctly... C++0x features were originally, HAS_*, but we decided that it should really be NO_* a while back. The HAS_* versions are still there for backwards compatibility.
Fair enough. What's the best way to handle code that is only using the HAS_ version and I guess hasn't been updated to use the NO_ version? See, for example, intrusive_ptr's move constructor. I guess the options are either: a) Make sure all preprocessor checks over the entire code base are changed to (HAS_ || !NO_) or (NO_ || !HAS_) depending on the statement, or b) Move one header up from the compiler specific headers, and then after the correct compiler-specific header has been included, check for the occurrence of every NO_, and set every corresponding HAS_ Zach
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Monday, February 15, 2010 5:54 AM Subject: Re: [boost] C++0x and MSVC 10
AMDG
Zachary Turner wrote:
On Sun, Feb 14, 2010 at 9:45 PM, Scott McMurray <me22.ca+boost@gmail.com>wrote:
On 14 February 2010 22:30, Zachary Turner <divisortheory@gmail.com> wrote:
It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following?
I thought the convention was, for standard features, to just have the _NO_ version, and check for #ifndef if you want it, rather than having to keep both _NO_ and _HAS_ versions of the same thing.
Possibly, to be honest I'm not familiar with the conventions surrounding these sorts of things and I couldn't find much documentation. The solution I came up with was based off of looking at the gcc header file, and noting that it does keep _NO_ and _HAS_ versions of the constants, and additionally in various header files I still see plenty of references to BOOST_HAS_xxx scattered around.
Either way, I guess some consensus needs to be reached, and maybe we should change the rest of the codebase to follow it so that all libraries agree on the convention.
If I recall correctly... C++0x features were originally, HAS_*, but we decided that it should really be NO_* a while back. The HAS_* versions are still there for backwards compatibility.
Hi, What do you think of including all the deprecated macros on config_deprecated.hpp file and force all the files using of the deprecated macros to use the new file (this seems less intrusive that forcing them to use the non deprecated macros). This new file could include also a #deprecated pagma so a warning will appear. I could prepare a patch if the Boost authors are interesteed. Best, Vicente
On 15 February 2010 13:14, vicente.botet <vicente.botet@wanadoo.fr> wrote:
What do you think of including all the deprecated macros on config_deprecated.hpp file and force all the files using of the deprecated macros to use the new file (this seems less intrusive that forcing them to use the non deprecated macros). This new file could include also a #deprecated pagma so a warning will appear.
That sounds like a bad idea to me, all you'll do is disable C++0x support in libraries that use the deprecated macros (since they're all checked using #ifdef). Better to just search for the macros and change them. Do we have a list of the deprecated macros? Daniel
On Mon, Feb 15, 2010 at 4:43 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
On 15 February 2010 13:14, vicente.botet <vicente.botet@wanadoo.fr> wrote:
What do you think of including all the deprecated macros on config_deprecated.hpp file and force all the files using of the deprecated macros to use the new file (this seems less intrusive that forcing them to use the non deprecated macros). This new file could include also a #deprecated pagma so a warning will appear.
That sounds like a bad idea to me, all you'll do is disable C++0x support in libraries that use the deprecated macros (since they're all checked using #ifdef). Better to just search for the macros and change them. Do we have a list of the deprecated macros?
I agree with Daniel. We need to focus on the non-deprecated forms, and move away from the deprecated forms as quickly as possible. --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "boost" <boost@lists.boost.org> Sent: Tuesday, February 16, 2010 12:34 AM Subject: Re: [boost] C++0x and MSVC 10
On Mon, Feb 15, 2010 at 4:43 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
On 15 February 2010 13:14, vicente.botet <vicente.botet@wanadoo.fr> wrote:
What do you think of including all the deprecated macros on config_deprecated.hpp file and force all the files using of the deprecated macros to use the new file (this seems less intrusive that forcing them to use the non deprecated macros). This new file could include also a #deprecated pagma so a warning will appear.
That sounds like a bad idea to me, all you'll do is disable C++0x support in libraries that use the deprecated macros (since they're all checked using #ifdef). Better to just search for the macros and change them. Do we have a list of the deprecated macros?
I agree with Daniel. We need to focus on the non-deprecated forms, and move away from the deprecated forms as quickly as possible.
If there is a plan to remove the deprecated froms soon, I agree. When the deprecated forms will be removed? Vicente
On 15 February 2010 23:40, vicente.botet <vicente.botet@wanadoo.fr> wrote:
If there is a plan to remove the deprecated froms soon, I agree. When the deprecated forms will be removed?
Before we can consider removing the old macros, we have to update all the places where they're used in boost. Daniel
On Mon, Feb 15, 2010 at 6:03 PM, Daniel James <daniel_james@fmail.co.uk>wrote:
On 15 February 2010 23:40, vicente.botet <vicente.botet@wanadoo.fr> wrote:
If there is a plan to remove the deprecated froms soon, I agree. When the
deprecated forms will be removed?
Before we can consider removing the old macros, we have to update all the places where they're used in boost.
The entire list of macros that need to be deprecated should be as follows. Someone correct me if I'm wrong, it was a little tricky finding all of these. BOOST_HAS_DECLTYPE [proto] BOOST_HAS_RVALUE_REFERENCES [interprocess, smart_ptr, thread, unordered] BOOST_HAS_STATIC_ASSERT [static_assert] BOOST_HAS_CONCEPTS [xpressive] BOOST_HAS_VARIADIC_TMPL [smart_ptr, unordered, interprocess, proto] Many more _HAS_ macros are defined in the various compiler config files but never referenced. Obviously those should be eliminated too.
----- Original Message ----- From: "Zachary Turner" <divisortheory@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, February 16, 2010 7:02 AM Subject: Re: [boost] C++0x and MSVC 10
On Mon, Feb 15, 2010 at 6:03 PM, Daniel James <daniel_james@fmail.co.uk>wrote:
On 15 February 2010 23:40, vicente.botet <vicente.botet@wanadoo.fr> wrote:
If there is a plan to remove the deprecated froms soon, I agree. When the
deprecated forms will be removed?
Before we can consider removing the old macros, we have to update all the places where they're used in boost.
The entire list of macros that need to be deprecated should be as follows. Someone correct me if I'm wrong, it was a little tricky finding all of these.
BOOST_HAS_DECLTYPE [proto] BOOST_HAS_RVALUE_REFERENCES [interprocess, smart_ptr, thread, unordered] BOOST_HAS_STATIC_ASSERT [static_assert] BOOST_HAS_CONCEPTS [xpressive] BOOST_HAS_VARIADIC_TMPL [smart_ptr, unordered, interprocess, proto]
Many more _HAS_ macros are defined in the various compiler config files but never referenced. Obviously those should be eliminated too.
As concepts are not on the standard proposal we should let tas _HAS_. BTW, is there a macro to know if the compiler supports macros with variable arguments? Something like BOOST_NO_VARIADIC_MACROS Best, Vicente
Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
BTW, is there a macro to know if the compiler supports macros with variable arguments? Something like BOOST_NO_VARIADIC_MACROS
if you are going to add one, you might also want to add a macro for detecting the following MSVC bug, as it affects a lot of use cases, I think, including yours. the sample code I sent you off-list doesn't seem to work on MSVC because of this bug. not sure if there is a workaround. http://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-m... MS doesn't seem too interested in fixing it.
On Tue, Feb 16, 2010 at 1:02 AM, Zachary Turner <divisortheory@gmail.com> wrote:
The entire list of macros that need to be deprecated should be as follows. Someone correct me if I'm wrong, it was a little tricky finding all of these.
Thanks for doing this!
BOOST_HAS_DECLTYPE [proto] BOOST_HAS_RVALUE_REFERENCES [interprocess, smart_ptr, thread, unordered] BOOST_HAS_STATIC_ASSERT [static_assert]
trunk changed.
BOOST_HAS_CONCEPTS [xpressive]
As Vicente pointed out, that use is OK.
BOOST_HAS_VARIADIC_TMPL [smart_ptr, unordered, interprocess, proto]
So it looks like the maintainers for these libs need to update their code: interprocess proto smart_ptr thread unordered --Beman
participants (7)
-
Beman Dawes -
Daniel James -
Scott McMurray -
Steven Watanabe -
strasser＠uni-bremen.de -
vicente.botet -
Zachary Turner