Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-06-06 17:32:22

Le 06/06/2016 à 12:59, Edward Diener a écrit :
> On 6/6/2016 4:52 AM, Rob Stewart wrote:
>> On June 5, 2016 8:30:50 PM EDT, Edward Diener 
>> <eldiener_at_[hidden]> wrote:
>>> On 6/5/2016 5:55 PM, Rob Stewart wrote:
>>>>>
>>>>> It does involve more work and macros are still being used, although
>>> not
>>>>> to name the namespace. I honestly think that CXXD's solution is
>>> cleaner
>>>>> and more flexible. Lifting constructs which are normally accessed
>>>>> through one namespace to another namespace in that way seems to me a
>>>>> kludge. I am not sure of all the ramifications of doing this but I
>>>>> would
>>>>> be wary of doing such a thing myself.
>>
>> Vicente's approach, of I have it right, is pretty simple:
>>
>> namespace boost {
>> namespace something {
>>    using std::thread;
>>    // or (conditionally selected)
>>    using boost::thread;
>> } }
>>
>> With that, boost::something::thread is the name to use in the user's 
>> code.
>>
>> The selection of what to import into the new namespace is managed by 
>> the preprocessor, so it can be overridden, too.
>>
>>> My thought is generally that CXXD represents the easiest approach and
>>> that importing either side of a dual library's namespace into another
>>> common namespace, no matter how it is controlled, does not represent
>>> anything better than what CXXD has to offer.
>>
>> Allowing the user to just refer to boost::something::thread, rather 
>> than CXXD_THREAD::thread is less jarring to read, if nothing else. I 
>> don't think it offers much beyond that, though Vicente may have more 
>> information.
>>
>>> Furthermore, although I haven't had the time or knowledge to work
>>> through all possible situations I believe that Vicente's approach could
>>> have problems involving customization points for a library, ADL, and/or
>>> template specializations.
>>
>> I don't think that's a problem for the library code itself and, since 
>> users are not generally permitted to open the std namespace, I don't 
>> think it would be a problem otherwise. Still, Vicente is best able to 
>> answer.
>>
>>> Of course I could be
>>> wrong about this and everything just "works" despite the different
>>> namespace in which all those constructs are now operating. But why deal
>>> with those possible problems in the first place.
>>
>> If those are not problems, then there's nothing, real or imagined, to 
>> deal with.
>>
>>> In CXXD the namespace stays the same and I think this is much safer.
>>> The
>>> fact that a simple object-like macro refers to the correct namespace at
>>> all times bothers me not at all simply because it is a macro.
>>
>> If the alternative works correctly, without exposing a macro to 
>> users, I suspect you'll have a much easier time with a review, and 
>> the burden on you doesn't seem much (any?) heavier.
>
> We will have to agree to disagree.

I can not say yet if your approach is better or not. In order to say if 
it is better it should be compared and then we need the list of 
advantages and and liabilities of each approach.

I have given some limitation of the CXXD approach:
* The fact that the name space is a macro is not the worst one for me 
and I can live with it if there is some additional advantage fro the user,
* Template specialization needs an additional macro in general (e.g. for 
Boost.Fusion). You have not fall in this case yet as maybe all the Boost 
libraries were in the boost namespace.
* CXXD is unable to rename (e.g. enable_if versus enable_if_c). Well not 
exactly, but it needs to apply that is something equivalent to CSBL.
* Documenting what the library exactly provides is almost impossible. It 
is up to the user to know exactly what is common between the dual libraries.

Importing approach should have also a lot of drawbacks and a tier person 
is often more critical to see them.
* Possibly more maintenance, as you suggested.
* Template specialization needs ALWAYS an additional macro in general.
* Complexity: some possible issues that need to be confirmed.
* Even if documentation could be more explicit it will be also difficult 
to say exactly what is the exact semantics of the proposed interface. 
Reducing the interface only to whatever match the standard would 
simplify the documentation.

I'm not sure I'm completely impartial.

I'm almost sure that your approach would have a better added value / 
cost ratio.

But people will be asking for more :(
We can always say, no, this is out of the scope of the library.

Best,
Vicente