Re: [boost] [config] std::unique_ptr, std::ref detection?

Subject: Re: [boost] [config] std::unique_ptr, std::ref detection?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-03-01 18:34:46

On Thu, Mar 1, 2012 at 3:11 PM, Marshall Clow <mclow.lists_at_[hidden]> 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_at_[hidden]>
> wrote:
> >
> >> 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.
> >>
> >
> > 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-INITIALIZER-LISTS-td2662739.html
>
> 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