Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-05 21:18:46

On 6/5/2015 8:14 PM, Rob Stewart wrote:
> On June 5, 2015 10:42:50 AM EDT, Edward Diener <eldiener_at_[hidden]> wrote:
>> On 6/5/2015 10:00 AM, Rob Stewart wrote:
>>> On June 5, 2015 5:30:03 AM EDT, Edward Diener
>> <eldiener_at_[hidden]> wrote:
>>>
>>>> It is very easy to use. For library 'XXX':
>>>>
>>>> 1) Just include the particular Boost.config header provided for a
>>>> particular interoperable library XXX:
>>>>
>>>> #include <boost/config/cpp/XXX.hpp>
>>>
>>> I noticed in your PR that you also provide a header to get all such
>> headers at once. I wonder whether the individual headers are really
>> that useful. You could keep the implementation you have, but just
>> document the one header.
>>
>> The one header is documented. I have the individual headers to avoid
>> flooding the macro namespaces with lots of macros you are not going to
>> use.
>
> I know you documented the everything header. I was suggesting that you not document or mention the others.
>
> I don't think the flooding issue you mention is significant. The macro names are reasonably unique and I don't think there are so many that you need worry about defining them all.

I think giving people choices is better than not doing so. Why bring in 
what isn't needed for any give TU ?

>
>>>> 2) Include that library's main header file using the macro provided
>>>> for that library:
>>>>
>>>> #include BOOST_CPP_XXX_HDR
>>>
>>> Why do you have "CPP" in that name? BOOST_XXX_HDR would seem
>> sufficient. I also would suggest using HEADER rather than HDR.
>>
>> I like to avoid macro name clashes, Having a common prefix, such as
>> CPP, tends to do that.
>
> I understand the concern, but I don't think BOOST_ATOMIC_HEADER, BOOST_ATOMIC_NAMESPACE, BOOST_ATOMIC_IS_STD, etc. would be likely to clash.

Actually I do, and I think you are wrong. It is customary for Boost 
libraries which have macros to name them starting with BOOST_XXX_ where 
XXX is the library name. Why should I worry about potential clashes by 
following the exacts same convention for my macros.

OTOH I do like your suggestion about changing the name of the 
BOOST_CPP_HAS_XXX macros to something like BOOST_CPP_XXX_IS_STD, or 
better yet BOOST_CPP_XXX_USES_STD_LIB, as being much more descriptive 
even if less terse.

>
>> I could even change  BOOST_CPP_XXX_NS to BOOST_CPP_XXX_NAMESPACE and have everybody type
>> out the fully explicit names.
>
> HEADER won't appear very often, so I thought spelling it out would be fine. The namespace macro might be used more often, so I didn't suggest expanding it. OTOH, the longer name can be mitigated by a namespace alias.

OK, that seems reasonable. the BOOST_CPP_XXX_HEADER would only be used 
once each TU so I agree with you on that. No need for the HDR abbreviation.

I want to wait until all discussion of the macros are complete before I 
implement macro naming changes, but I do appreciate your suggestions.