Re: [boost] Cxx dual library

5 Jun 2016

      On 6/4/2016 9:28 PM, Rob Stewart wrote:
...
On June 4, 2016 2:01:25 PM EDT, Edward Diener  wrote:
...
...
Le 03/06/2016 à 18:46, Edward Diener a écrit :
...
On 6/3/2016 11:51 AM, Vicente J. Botet Escriba wrote:
...
Le 03/06/2016 à 12:58, Edward Diener a écrit :
...
On 6/3/2016 1:54 AM, Vicente J. Botet Escriba wrote:
> Le 03/06/2016 à 01:26, Edward Diener a écrit :
>> On 6/2/2016 5:40 PM, Vicente J. Botet Escriba wrote:
>>> Le 02/06/2016 à 20:55, Edward Diener a écrit :
>>>
>> I am not as afraid of macros as you appear to be.
> I'm not afraid of macros. In general I prefer to don't use them
when I
> can use an alternative solution.
I am with you if the alternative solution is easy to use. But when
it
involves a great deal of work on the end-user's part I think a
macro-based solution is OK.
There is no more work on the user's side but on the developer's
side.
And for the user it is better to don't use macros as far as
...
...
...
Could you describe what the user need to do in addition?
I do not agree with a blanket statement of:
"And for the user it is better to don't use macros as far as
On 6/4/2016 12:16 PM, Vicente J. Botet Escriba wrote:
possible.
possible."
...
...
It is only better to not use macros when an equally viable and easy
to
...
use solution is available.
How my approach is worst for the users?
I do not understand what you mean by:
"Could you describe what the user need to do in addition?"
You said : "But when it involves a great deal of work on the
end-user's
part I think a macro-based solution is OK."
My approach don't request anything additional respect to a macro
solution.
I am sure I said that when an alternative involves a great deal of work
on the end-user's part I think a macro-based solution is OK. Please
read what I said again.
Edward, you've missed that Vicente doesn't see that importing either a Boost or a Standard Library solution, into a common namespace requires anything more of the user.
The user would always use the new, common namespace name for something, regardless of its original namespace. For example, foo::x is the common name, but x may have been introduced into the foo namespace, by a using directive, from the boost or the std namespace.
In the end, the user always includes the foo header and uses the foo name. There are no macros in the user's code. Both solutions select one implementation or the other. Yours refers to the namespace of the selected implementation with a macro, while his just uses namespace foo.
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.

You also don't have the technique of overriding the dual library choice 
that you have with CXXD, unless you manually change some source, which 
you may not have access to in the first place. But if you think the CXXD 
macros are going to cause problems, just because they are macros and 
therefore "evil', by all means roll your own solution as Vicente has done.