Thomas Witt <witt@acm.org> writes:
Dave,
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
For the record I don't think it's irritating at all. It very clearly states what is going on. I can see it being cumbersome though.
Cumbersomeness is irritating ;-)
You are missing my point ;-)
I don't think so, but maybe you should try again.
The user can always call the hook unqualified. That's _going_ to be a public part of the library's interface.
Well, if you look at it this way then the _only_ functionality boost::begin provides is a syntactic shortcut. I.e.
boost::begin(r);
and
using boost::range_begin; range_begin(r);
are functionally equivalent.
Did I miss something?
I don't think so. Except maybe that all that C++ provides over C can be viewed as syntactic shortcuts ;-)
In this case we have the real name in the helper and some artificially uglified name in all class interfaces. This doesn't feel right to me.
It's not right, but the language spec (especially when combined with GCC's implementation choices) doesn't give us better options today. Do try to remember that although the "artificially uglified name" will appear in the interfaces of all classes that model the range concept, there will probably be even more uses of the "real name" in user code.
You could also argue that boost::begin's name does not really describe what it's doing. Having a namespace qualified call disguise an unqualified call is another issue that gives me headaches.
Yes, the whole area of dispatching and customization of generic functions is nasty in C++. I've known it's problematic for a long time, but had a hard time expressing how bad the problem is in a way that would communicate to someone who doesn't do heavy generic programming day in and day out. Doug Gregor and I just resolved some related aspects of http://tinyurl.com/6z528 (http://news.gmane.org/find-root.php?message_id=%3cupsxsbv5h.fsf%40boost%2dco...) today, and in the process I think I learned enough to show convincingly that something needs to be done. I'm going to write up our findings next; we'll see how that comes out. -- Dave Abrahams Boost Consulting www.boost-consulting.com