From: Thomas Witt (witt_at_[hidden])
Date: 2005-03-24 22:04:27
David Abrahams wrote:
> Thomas Witt <witt_at_[hidden]> 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
-- Thomas Witt witt_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk