|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-02-26 05:35:34
Daniel Frey <daniel.frey_at_[hidden]> writes:
> David Abrahams wrote:
>> Daniel Frey <daniel.frey_at_[hidden]> writes:
>>
>>>>Incidentally, it's almost always possible to detect whether the first
>>>>argument supports operator += or operator-=. That might be a good way
>>>>to decide whether to advance/regress it.
>>>
>>>If is_iterator yields false
>> There is no is_iterator trait AFAIK. And I wasn't suggesting that.
>> I was suggesting something more like is_+=able and is_-=able traits.
>>
>>>this is good to distinguish the rest,
>
> Sorry, during shortening my previous mail before posting, one sentence
> got lost :) I was suggesting to add is_iterator,
If you can figure out how to do that, you will be a hero to many.
> because if it yields true we should IMHO use std::advance.
Why?
> Only if it yields false, we should use your suggestion to
> distinguish +=able types from ++able types to use an efficient
> O(1)-implementation when possible, an O(n)-implementation otherwise.
>
>>>yes. But the first question is, whether we want to enhance the 2-arg
>>>version of next/prior or if we simply rename them to
>>>e.g. advanced/regressed. I'd be happy with the latter. Comments?
>> I find those names rather awful for functions; no offense intended.
>
> No problem, the names are not important. The important part is,
> whether we want to make the 2-arg version iterator-only.
No, the names are important. The 2-arg version of a function with
the same name shouldn't add major new restrictions on its inputs.
-- 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