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> boost-consulting.com> writes:
>
>>
>> Thorsten Ottosen <nesotto <at> cs.aau.dk> 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

   range_begin(x)

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
boost/detail/is_incrementable.hpp

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk