[Boost-users] Re: [Foreach]TroubleiteratingoverBoost.MultiIndexcontainers

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-04 10:34:28

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> David Abrahams wrote:
>>>
>>>> ADL might not be the best customization solution.
>>>
>>> You keep saying that, but I keep disagreeing. ADL is the best
>>> customization solution. Not flawless, just better than any of the
>>> alternatives.
>>
>> I guess I haven't seen enough be definitively convinced one way or the
>> other.  I have heard stories from people who switch to dispatching via
>> specialization and report how much better things get.  Furthermore,
>> Daveed Vandevoorde has convinced me that it is far easier to reason
>> about.  The rules for matching partial specializations are trivial
>> compared to the mess you have to consider when there is overloading.
>> The inconvenience of specialization is ugly, but it seems like a
>> one-time cost that may be justified for what it buys us.
>
> That's the thing. It doesn't actually buy us anything. 

- Simpler matching rules
- Customizability for built-in types
- Code is explicit about what operation it's customizing and what
  operation it's calling.
- A few more, but you're disputing them below...

> It only claims to 
> avoid potential problems.
>
> * Uglier syntax for defining a specialization.
>
> * Coupling; you need to include a primary template.
>
> * Does not allow a base-specific version to be picked up automatically for 
> derived classes.
>
> * Does not allow non-exact matches.
>
> * If four libraries need the same operation, you need to specialize four 
> primary templates.

If four libraries happen to specify the exact same name and semantics
for something, I'd say it's a well-known standard and _maybe_ you
should have been using ADL in the first place.  But in general, the
chance of that happening is infinitesimal.  Where there are function
name collisions, the likelihood is that requirements will be similar,
but not identical.

> In practice people tend to respect de-facto standards; a + b is an
> addition, and swap(a, b) swaps a and b. The main fight is over who
> gets to keep the primary template.

No, the problem is what happens when you have no de-facto standard.
Customizable interfaces get invented, and when they do, they are just
some new thing.  Everybody wants to think that they will invent the
de-facto standard use for a name, but sometimes these things collide.
Just look at _1, _2, et. al.

> But this is not really a problem with ADL customization points,
> because in their purest form, there is no primary template. The
> primary template is usually a compatibility workaround for types
> that do not support the ADL interface yet.

I think you're being just a tiny bit too sanguine here.  There are
layers of concepts that need to be built upon commonly-used types, and
there's a great danger that different libraries will pick the same
simple names for different operations in their own domains.  Just
consider the widespread use of numeric types in all kinds of
domain-specific applications.  Is every library going to pick the same
meaning for 

        zero(x)

??

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com