[config] std::unique_ptr, std::ref detection?
Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".
On Feb 28, 2012, at 8:20 AM, Peter Dimov wrote:
Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".
At the moment, I am using: #if __cplusplus >= 201103L -- 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
"Peter Dimov" <pdimov@pdimov.com> writes:
Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".
To figure out if a specific library has been installed I've use CMakes try_run [1] to check if the compiler supports what I need and define the necessary macros. Most build-system should support some analogue. Although this is a build-only solution and might not be what you are looking for. [1] : http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:try_run -- Philipp Moeller
Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".
I'd prefer not to get too fine grained about this if possible, but are these the only additions to those headers? If so how about BOOST_NO_0X_HDR_MEMORY and BOOST_NO_0X_HDR_FUNCTIONAL which would mirror the existing macros fairly closely? John.
John Maddock wrote:
Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".
I'd prefer not to get too fine grained about this if possible, but are these the only additions to those headers? If so how about BOOST_NO_0X_HDR_MEMORY and BOOST_NO_0X_HDR_FUNCTIONAL which would mirror the existing macros fairly closely?
No, these are not the only additions; <memory> has at least shared_ptr and weak_ptr in C++11, and <functional> has function, bind, mem_fn, hash. But it looks workable enough. I agree that adding a macro for each and every addition would get unwieldy.
I'd prefer not to get too fine grained about this if possible, but are these the only additions to those headers? If so how about BOOST_NO_0X_HDR_MEMORY and BOOST_NO_0X_HDR_FUNCTIONAL which would mirror the existing macros fairly closely?
No, these are not the only additions; <memory> has at least shared_ptr and weak_ptr in C++11, and <functional> has function, bind, mem_fn, hash. But it looks workable enough. I agree that adding a macro for each and every addition would get unwieldy.
OK, here's what I propose to add unless there are objections about the names: BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc). Cheers, John.
On Thu, Mar 1, 2012 at 5:55 PM, John Maddock <boost.regex@virgin.net> wrote:
I'd prefer not to get too fine grained about this if possible, but are these the only additions to those headers? If so how about BOOST_NO_0X_HDR_MEMORY and BOOST_NO_0X_HDR_FUNCTIONAL which would mirror the existing macros fairly closely?
No, these are not the only additions; <memory> has at least shared_ptr and weak_ptr in C++11, and <functional> has function, bind, mem_fn, hash. But it looks workable enough. I agree that adding a macro for each and every addition would get unwieldy.
OK, here's what I propose to add unless there are objections about the names:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now? -- Olaf
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd like to be consistent with existing practice, and don't much fancy changing all the existing ones... John.
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd like to be consistent with existing practice, and don't much fancy changing all the existing ones…
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost all in boost/config and libs/config (in fact, most are in libs/config/test). If people think this is a good idea, and no one else wants to do it, I can do it this weekend. -- 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 wrote:
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd like to be consistent with existing practice, and don't much fancy changing all the existing ones...
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I can do it this weekend.
I think it is a very good idea to switch to 11, though it should probably be "CPP11" or "CXX11". (Sound familiar?) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mar 1, 2012, at 10:29 AM, Marshall Clow wrote:
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd like to be consistent with existing practice, and don't much fancy changing all the existing ones…
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I can do it this weekend.
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one. The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config). I think I'll make that change first; unless someone complains. -- 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
On Thu, Mar 1, 2012 at 2:30 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd
On Mar 1, 2012, at 10:29 AM, Marshall Clow wrote: like to be consistent with existing practice, and don't much fancy changing all the existing ones…
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost
all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I
can do it this weekend.
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS
There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one.
The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config).
I think I'll make that change first; unless someone complains.
Are these only internal macros? If these are public, it's possible you'll break some user code. Are we only speaking of macros that indicate whether specific C++11 constructs are available upon inclusion of a given header (that has been added or changed in C++11 relative to C++03)? - Jeff
On Mar 1, 2012, at 2:58 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Mar 1, 2012 at 2:30 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd
On Mar 1, 2012, at 10:29 AM, Marshall Clow wrote: like to be consistent with existing practice, and don't much fancy changing all the existing ones…
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost
all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I
can do it this weekend.
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS
There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one.
The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config).
I think I'll make that change first; unless someone complains.
Are these only internal macros? If these are public, it's possible you'll break some user code.
Are we only speaking of macros that indicate whether specific C++11 constructs are available upon inclusion of a given header (that has been added or changed in C++11 relative to C++03)?
Yes, the BOOST_NO_0X macros are C++11 specific (or rather, indicate the absence of C++11 features) As for BOOTS_NO_INITIALIZER_LISTS, people were asking for it to be removed back in 2009: http://boost.2283326.n4.nabble.com/config-Deprecate-remove-BOOST-NO-INITIALI... Daniel James claimed that he was the only one using it, then. Opinions? I don't mind doing the cleanup, but I certainly don't want to do it more than once. -- 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
On Thu, Mar 1, 2012 at 3:11 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 1, 2012, at 2:58 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Mar 1, 2012 at 2:30 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of <functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart
BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc).
0x? Shouldn't it be 11 by now?
Um, yes, it's just that we have all these 0X macros already and I'd
On Mar 1, 2012, at 10:29 AM, Marshall Clow wrote: pointers. like to be consistent with existing practice, and don't much fancy changing all the existing ones…
Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost
all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I
can do it this weekend.
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS
There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one.
The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config).
I think I'll make that change first; unless someone complains.
Are these only internal macros? If these are public, it's possible you'll break some user code.
Are we only speaking of macros that indicate whether specific C++11 constructs are available upon inclusion of a given header (that has been added or changed in C++11 relative to C++03)?
Yes, the BOOST_NO_0X macros are C++11 specific (or rather, indicate the absence of C++11 features)
I know this is probably obvious, but these macros are *additionally* always associated with a construct provided by a header, correct? Is it the case that the only BOOST_NO_0X macros are the BOOST_NO_0X_HDR macros? As for BOOTS_NO_INITIALIZER_LISTS, people were asking for it to be removed
back in 2009:
http://boost.2283326.n4.nabble.com/config-Deprecate-remove-BOOST-NO-INITIALI...
Daniel James claimed that he was the only one using it, then.
I think the important distinction is "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 wasn't sure whether initializer lists required a header, so I agree with Daniel that it's probably redundant. Opinions? I don't mind doing the cleanup, but I certainly don't want to do
it more than once.
Of course. I was just looking for clarity on what the difference between NO_INITIALIZER_LISTS (missing compiler support) and NO_0X_HDR_INITIALIZER_LISTS (missing construct in a header) was. - Jeff
On 1 March 2012 23:34, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
I think the important distinction is
"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 wasn't sure whether initializer lists required a header, so I agree with Daniel that it's probably redundant.
I was wrong, C++11 added other uses which don't require the header. Although I don't think portable code would ever need to take advantage of that. The situation with the visual c++ 10 beta was that initializer lists weren't supported, but the header was present. In that case BOOST_NO_INITIALIZER_LISTS would be defined, but BOOST_NO_0X_HDR_INITIALIZER_LISTS would not. A compiled library might still want to define methods which take initializer lists so that they can be used when linking with a different compiler that does support them. If you look at unordered, it now uses BOOST_NO_0X_HDR_INITIALIZER_LISTS in the headers (they support std::initializer_list but don't ever create one), but BOOST_NO_INITIALIZER_LISTS for test cases that actually use an initializer list. But.... it looks like including the header in Visual C++ 10 was actually a mistake: http://connect.microsoft.com/VisualStudio/feedback/details/533464/the-initia... It's also confusing having the two macros, very easy to get wrong, and the potential use cases are pretty dubious.
On Sat, Mar 3, 2012 at 4:51 AM, Daniel James <dnljms@gmail.com> wrote:
On 1 March 2012 23:34, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
I think the important distinction is
"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 wasn't sure whether initializer lists required a header, so I agree
with
Daniel that it's probably redundant.
I was wrong, C++11 added other uses which don't require the header. Although I don't think portable code would ever need to take advantage of that.
The situation with the visual c++ 10 beta was that initializer lists weren't supported, but the header was present. In that case BOOST_NO_INITIALIZER_LISTS would be defined, but BOOST_NO_0X_HDR_INITIALIZER_LISTS would not. A compiled library might still want to define methods which take initializer lists so that they can be used when linking with a different compiler that does support them.
If you look at unordered, it now uses BOOST_NO_0X_HDR_INITIALIZER_LISTS in the headers (they support std::initializer_list but don't ever create one), but BOOST_NO_INITIALIZER_LISTS for test cases that actually use an initializer list.
But.... it looks like including the header in Visual C++ 10 was actually a mistake:
http://connect.microsoft.com/VisualStudio/feedback/details/533464/the-initia...
LOL...nice.
It's also confusing having the two macros, very easy to get wrong, and the potential use cases are pretty dubious.
I'll ultimately defer to your and others' judgements here. Let me just say that it does sound like an argument can be made to continue to use BOOST_NO_INITIALIZER_LISTS (indicating whether the compiler correctly implements and supports (including header support) initializer lists) rather than BOOST_NO_0X_HDR_INITIALIZER_LISTS (header is present and...well who knows what else? should it only be undefined in the former case for BOOST_NO_INITIALIZER_LISTS?). The former macro is also more succinct. - Jeff
On 3 March 2012 18:08, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
I'll ultimately defer to your and others' judgements here. Let me just say that it does sound like an argument can be made to continue to use BOOST_NO_INITIALIZER_LISTS (indicating whether the compiler correctly implements and supports (including header support) initializer lists) rather than BOOST_NO_0X_HDR_INITIALIZER_LISTS (header is present and...well who knows what else? should it only be undefined in the former case for BOOST_NO_INITIALIZER_LISTS?). The former macro is also more succinct.
Not really my decision, but for the most part we are only concerned with the header. The macro will usually be used to determine the interface, not the implementation. We generally wouldn't write the following, as it's easier and less error prone to write just the C++03 implementation. void foo() { #if defined(BOOST_NO_INITIALIZER_LISTS) // C++03 implementation #else // C++11 implementation using initializer lists #endif }
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS
There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one.
OK.
The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config).
I think I'll make that change first; unless someone complains.
Suggest you "undocument" BOOST_NO_INITIALIZER_LISTS, remove the test in Boost.Config plus any reference to it in the config/compiler/*.hpp headers but leave it conditionally defined in boost/config/suffix.hpp as: #if defined(BOOST_NO_0X_HDR_INITIALIZER_LIST) && !defined(BOOST_NO_INITIALIZER_LISTS) #define BOOST_NO_INITIALIZER_LISTS #endif Then any legacy code out there that's using it won't be broken. Same procedure would apply to renaming the *_C0X_* macros: make sure the old deprecated ones are conditionally set in suffix.hpp so that legacy code isn't broken - it also means we can merge Boost.Config to release without worrying about the Boost libraries that depend upon it. I guess if we were really tidying up, then a nicely commented section in suffix.hpp for deprecated macros would be nice (there are a few in there already - just don't ask me which ones!). Cheers, John.
On Mar 2, 2012, at 1:43 AM, John Maddock wrote:
While looking at this, I noticed that we have two macros: BOOST_NO_0X_HDR_INITIALIZER_LIST and BOOST_NO_INITIALIZER_LISTS
There's an old thread from 2009 where the consensus was that "BOOST_NO_INITIALIZER_LISTS" should be removed in favor of the 0X one.
OK.
The only library that is using BOOST_NO_INITIALIZER_LISTS is Boost.Random (and some tests in Boost.Config).
I think I'll make that change first; unless someone complains.
Suggest you "undocument" BOOST_NO_INITIALIZER_LISTS, remove the test in Boost.Config plus any reference to it in the config/compiler/*.hpp headers but leave it conditionally defined in boost/config/suffix.hpp as:
#if defined(BOOST_NO_0X_HDR_INITIALIZER_LIST) && !defined(BOOST_NO_INITIALIZER_LISTS) #define BOOST_NO_INITIALIZER_LISTS #endif
Then any legacy code out there that's using it won't be broken.
Revision 77157. I did all this, and added a section in the config docs called "Deprecated Macros" Please take a look and let me know what I did wrong.
Same procedure would apply to renaming the *_C0X_* macros: make sure the old deprecated ones are conditionally set in suffix.hpp so that legacy code isn't broken - it also means we can merge Boost.Config to release without worrying about the Boost libraries that depend upon it.
I guess if we were really tidying up, then a nicely commented section in suffix.hpp for deprecated macros would be nice (there are a few in there already - just don't ask me which ones!).
Right. That's next. ;-) Since no one has piped up with a preference for CPP vs. CXX, I guess I'll choose. (Fires up the dice) -- 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
On Mar 3, 2012, at 1:07 AM, John Maddock wrote:
Since no one has piped up with a preference for CPP vs. CXX, I guess I'll choose. (Fires up the dice)
I guess CXX simply because CPP may be confused with the preprocessor?
Ok; it's done - commits #77194 and #77195 sed is my friend. All the BOOST_NO_0X_* macros are now deprecated; please use BOOST_NO_CXX11_* instead. The old macros are sill there, and will work - until we remove them, sometime in the future. I'll gin up a list of who uses them tomorrow. [ I'm sure that someone will let me know if I got anything wrong ] -- 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
Le 01/03/12 19:29, Marshall Clow a écrit :
On Mar 1, 2012, at 9:53 AM, John Maddock wrote:
BOOST_NO_0X_HDR_FUNCTIONAL - std lib doesn't have a complete implementation of<functional>, MSVC and gcc/libstdc++ seem to have added all the new features here on mass, so this seems reasonable. BOOST_NO_0X_SMART_PTR - no shared_ptr and unique_ptr. BOOST_NO_0X_ATOMIC_SMART_PTR - no atomic operations on smart pointers. BOOST_NO_0X_ALLOCATOR - no C++0x allocator support (allocator_traits etc). 0x? Shouldn't it be 11 by now? Um, yes, it's just that we have all these 0X macros already and I'd like to be consistent with existing practice, and don't much fancy changing all the existing ones… Searching for "BOOST_NO_0X" finds about 500 matches in 87 files, almost all in boost/config and libs/config (in fact, most are in libs/config/test).
If people think this is a good idea, and no one else wants to do it, I can do it this weekend.
Hi, don't forget to maintain the BOOST_NO_0X for users backward compatibility and change the doc to state that these macros are deprecated and that will be removed e.g. 4 versions later. A macro to don't provide them as BOOST_CONFIG_DONT_PROVIDE_0X_MACROS will be useful also, to ensure we don't use them during the deprecated period. Best, Vicente
participants (9)
-
Daniel James -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Marshall Clow -
Olaf van der Spek -
Peter Dimov -
Philipp Moeller -
Stewart, Robert -
Vicente J. Botet Escriba