Boost logo

Boost :

Subject: Re: [boost] [MPL] A Proposal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-02-29 14:42:46


On 2016-02-29 20:39, Edward Diener wrote:
> On 2/29/2016 3:45 AM, Andrey Semashev wrote:
>> On 2016-02-29 06:48, Edward Diener wrote:
>>> On 2/28/2016 7:13 PM, Andrey Semashev wrote:
>>>> On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra_at_[hidden]>
>>>> wrote:
>>>>> Dear Community,
>>>>
>>>> [snip]
>>>>
>>>>> My proposal is to make Metal officially into a new revision of
>>>>> Boost.MPL's
>>>>> API, essentially MPL2 as the original proposal by Robert Ramey put it,
>>>>> merging both into one single TMP library. The idea would be to
>>>>> provide a
>>>>> thin proxy for the current Boost.MPL API which would have two backends
>>>>> configurable by preprocessor switches: the original implementation
>>>>> and a
>>>>> another one based on Metal.
>>>>
>>>> I don't think it needs to be controlled with preprocessor switches. In
>>>> fact, it's best to avoid config macros as much as possible because it
>>>> complicates the use of the library in other libraries.
>>>
>>> I disagree with this. Simply because you are compiling with c++11 on up
>>> will not necessarily mean that you want to use the Metal additions to
>>> Boost.MPL rather than the current Boost.MPL. Certainly the programmer
>>> should have a choice even when C++11 is be used in the compilation.
>>
>> I don't see a use case where you would want a C++03 implementation on a
>> C++11 capable compiler. On the other hand I can easily see the situation
>> where several libraries using Boost.MPLv2 conflict because they have
>> defined different config macros for it.
>
> You have a good point with your last sentence. The best thing might be
> to put the MPLv2 header files in its own separate version2 sub-directory
> structure.

...and its own separate namespace. With that, it doesn't really differ
from a completely separate library, which I was suggesting. No need to
drag the MPLv2 naming as well.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk