"David Abrahams" wrote in message
news:uacpk414w.fsf@boost-consulting.com...
| "Thorsten Ottosen" writes:
|
| > "Arkadiy Vertleyb" wrote in message
| > | Well, then I hate to say this, but IMHO this is a problem in the
Boost.Range
| > | design :-(
| >
| > It is deliberate design.
|
| It might still be a design mistake.
well, yes, it could be.
| > All generic code that uses boost.range should use unqualified calls
| > to enable ADL.
| >
| > <aside>
| > It is possible to imagine alternative designs where
| > all calls to end(c) can be made qualified and still enable
| > ADL; however, it requires the unqulified call of another function
| > inside boost::end(c) , say adl_end(c), to enable ADL of that function.
| > </aside>
|
| ADL might not be the best customization solution. Problems with ADL
| are well-known, and there are other mechanisms; in this case static
| member functions of a class template specialization might have been
| better... especially since you can't stick overloads in std. For
| example:
|
| namespace boost { namespace ranges {
|
| template <class Range>
| struct traits;
|
| template <class Range>
| typename traits<Range>::iterator begin(Range& r)
| {
| return traits<Range>::begin(r);
| };
|
| // ... etc...
| }}
|
|
|
| > | I am not really that familiar with this library, but I assume it has to
do
| > | with containers, correct? Assume the following usage (pseudocode)
| > |
| > |
Range(std::vector | ector> > > )
| > |
| > | Now ADL will use std, boost, MyNamespace, boost::multi_index, and
boost::mpl
| > | to find Range. There is absolutely no guarantee that it won't find
| > | conflicting functions :-(
| >
| > I don't get this. Surely one of the functions would be a better match than
| > the others and hence called.
|
| The problem is that controlling which is the best match is sometimes
| very difficult. Sometimes the best match doesn't get called.
then how can it be the best match then?
| Sometimes there is ambiguity. ADL is a very blunt instrument.
If the implementation was to use a class template, what would be preffered
naming?
Would you want one big fat class with all the functions?
Or would you like a class for each function, say for end(), std::end_impl<T>?
-Thorsten
