Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-06 18:42:50

On 6/6/2016 5:32 PM, Vicente J. Botet Escriba wrote:
> 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,

The advantage is that it works. The disadvantage of using a macro is in 
your own mind and other for whom using a simple distinctly named macro 
is some sort of a problem.

> * 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.

This is not true. You came up with a case involving Boost.Fusion, and I 
responded that Boost Fusion is not part of any dual library. From there 
you jump to the erroneous conclusion that specializations will not work 
with CXXD. In fact it is quite probable that specializations previously 
made for either side of a dual library will not work in your 
implementation since you are changing the name of the namespace and I am 
not.

> * 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.

CXXD can rename things with another equivalent macro, if I chose to do 
that. I did not so choose since it is not needed. CXXD does have the 
current ability to rename macros which exist in both sides of a dual 
library. It is already done for the atomic implementation, which is the 
only dual implementation in which it is needed. The form is 
CXXD_XXX_MACRO for a given XXX implementation and it is documented in 
the CXXD docs. Clearly if I can use a macro to rename equivalent macros 
I can use a macro to rename equivalent, but syntactical different named, 
constructs. But I decided to avoid that because I did not want to create 
a dual library where the syntax for equivalent functionality was not the 
same and I did not want to create a one-off situation for particular 
dual libraries. A candidate for using specific CXXD macros for renaming 
equivalent functionality with different syntax in a potential dual 
library is 'enable_if' since the Boost names and the C++ standard names 
are different for the same basic 'enable_if' functionality ( look it up 
). But I have resisted doing so. I may try to do so just to see what the 
reactions of others are, but given the dislike people have for using 
macros, despite the overwhelming success of Boost PP for Boost library 
authors, I don't anticipate that others will see the benefit.

> * 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.

Documenting what the library provides is completely possible and has 
been done to the best of my ability. Documenting any differences between 
the same syntax possibly providing different functionality in any of the 
28 different dual libraries is not a responsibility of CXXD as I see it. 
But I highly doubt that there are significant numbers of differences 
using the same syntax in the different dual libraries. That some side of 
a dual library sometimes has additional functionality compared to them 
other side I acknowledge. But that does not negate the usefulness of 
using the great amount of functionality in a dual library that is the 
same syntax and functions in the same way.

>
>
> 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.