Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-15 09:35:30

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> David Abrahams <dave <at>> writes:
>> Thorsten Ottosen <nesotto <at>> writes:
>> > then what about the following:
>> >
>> > Returns:
>> >
>> > x.first if x is an std::pair
>> > x if x is an array
>> > range_begin(x) if range_begin() can be found by ADL
>> > x.begin() otherwise
>> >
>> > ?
>> that would be an improvement. I think you need "otherwise," at the
>> beginning of all lines of the 2nd column but the first.
> like so
> x.first if x is an std::pair, otherwise
> x if x is an array, otherwise
> range_begin(x) if range_begin() can be found by ADL, otherwise
> x.begin()
> ?
> I personally think having one "otherwise" is ok. lot's of math do it like that.

I think I changed my mind. I agree with you.

>> Nitpicking,
>> range_begin(x) if range_begin() can be found by ADL
>> is not quite right. I think it's more like
>> range_begin(x) if range_begin(x) is well-formed in an arbitrary
>> namespace.
>> but I'm not certain I have that right either.
> hm...what about
> if range_begin() can be found in namespaces associated with
> x.

Not quite right, because range_begin() denotes a function taking no
arguments. You really should say


because it's an expression; it accounts for default arguments,
function templates, derived->base conversions, etc.

> OTOH, isn't that just ADL?

Yes, but the way you described it is just not correct; that's all.
Oh, and I suppose an overload of range_begin in the global namespace
would be found, provided it was declared before its point of use.
That's why something like

  range_begin(x) if range_begin(x) is well-formed

is more accurate.

>> Are you really
>> detecting whether range_begin can be found via ADL?
> No.

Then how are you arranging for the semantics to fall back to x.begin()
when range_begin(x) can't be found? If you're not really doing that,
you need to fix the docs.

>> I wrote code to do that trick, but I don't remember seeing it in
>> the range lib.
> Cool trick, though.

Yes; it's partly due to Doug Gregor. see

> The suggested spec. says that the return-type depends on 4 cases, it
> doesn't state how these cases are implemented. I don't think they need
> to state that.

I don't understand what you're trying to say. Specific implementation
details are not important, but the precise semantics of each case is

Dave Abrahams
Boost Consulting

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