David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
I don't think so. Except maybe that all that C++ provides over C can be viewed as syntactic shortcuts ;-)
Believe me I am aware of that ;-). Seriously, I am not opposed against the syntactic shortcut per se.
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.
I can see the problem. What I am unconvinced of is that the proposed solution is the correct solution to the overall problem. If this were some internal boost component meant to make boost library writing easier I would be perfectly happy, but we are talking about a library that deals with an important concept (ranges). I am particularly concerned with the scalability of the solution. How many ADL wrappers do we need to solve the problem? Will they become a legacy at some point?
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.
Agreed. On the other hand the usibility of these classes now takes a hit when Boost.Range isn't present. The class author can work around this by providing begin and range_begin functions. What might bring us back to square one. The class user might still have trouble to understand and memorize the right way to get at begin.
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.
I agree that something needs to be done. I just really want to be convinced that the proposed changes to boost::begin are the right solution Regards Thomas -- Thomas Witt witt@acm.org