"Peter Dimov"
David Abrahams wrote:
"Peter Dimov"
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