[boost] Re: [range] update on ADL hooks

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-23 19:55:41

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:42420638.2070604_at_boost-consulting.com...
|
| Thorsten Ottosen wrote:
| > "Eric Niebler" <eric_at_[hidden]> wrote in message
| > | But we can still come up with a convention used by any *new* ADL
| > | customization points. That's what you're asking about anyway, right?
| >
| > yes, agreed.
| >
| > | >
| > | > Free-standing functions seems to have slightly different
| > | > goals.
| > |
| > |
| > | You lost me. What goals?
| >
| > that boost:::foo() does ADL.
| >
| > new_clone() is used primarily inside the
| > containers and does therefore not suffer much
| > inconvenience.
|
|
| I'm still lost. What inconvenience?

the fact that you normally would have to
write

using namespace boost;
begin(r);

 > true, that could happen. the difference being that we might not.
| > In some sense it also seems wierd that the same customization point
| > should have different points in different libararies. Seems redundant.
|
|
| What is redundant? What different libraries? We're talking about the ADL
| customization points of /one particular library/.

are we? The thing is IMO that were are talking about customization
points of a concept, not a particular library.

| A customization point
| cannot be in two libraries simultaneously. I must have missed your point
| again. Please set me straight.

struct Foo
{ ... this is a range with adaptation ... }

iterator boost_range_begin( Foo& f );

iterator std_range_begin( Foo& f );

iterator adope_range_begin( Foo& f );

what is the difference between the three functions, apart from their name?

| > Another set of names could be
| >
| > begin_range()
| > end_range()
| > size_range()
|
|
| But you still haven't given me a reason I can understand why it
| shouldn't be "boost_range_begin()" etc..

I'm saying that it might not be the right solution; I don't see
why we should give the same concept different interfaces.

We are already protecting classes by a namespace, shouldn't that be enough.

-Thorsten