Re: [boost] Cxx dual library

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