Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-29 12:46:36

"Thomas Witt" <witt_at_[hidden]> wrote in message
| David Abrahams wrote:

| 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?

one for each function.

| Will they become
| a legacy at some point?

who knows?

| >
| > 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.

I don't think I get this.

| >
| > 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

What do you suggest then.

IMO the ADL problem is fairly simple and can be adequately
solved by the current proposed resolution.

A more "generic" mechanism when dealing with algorithms might be
ok, but I don't see why it is relevant in this context.


Boost list run by bdawes at, gregod at, cpdaniel at, john at