|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-02-24 20:26:45
Daniel Frey <daniel.frey_at_[hidden]> writes:
> David Abrahams wrote:
>> Daniel Frey <daniel.frey_at_[hidden]> writes:
>>
>>>I don't see any need to extend the legal use of next/prior to anything
>>> else than iterators.
>> It was already legal for non-iterators. What made you think
>> otherwise?
>
> The documentation and the way I was reading it :)
>
>>>as the documentation only speaks about iterators and never bothers
>>>to mention non-iterators. Thus, the bug is IMHO that it's not
>>>explicitly documented that next/prior's first argument must meet the
>>>interator requirements.
>> Sorry, dude, I get final say on original intent, since it was mine.
>
> Of course, but what's wrong with mentioning non-iterators
> explicitly?
Nothing's wrong with it; I just didn't happen to.
> Or more generally writing down the requirements then?
The requirements are clearly implied by the specification of the
function. This one is so simple that it's best to just show how it's
implemented.
> IIUC, you think that next/prior should work for all types that
> provide ++ and --, plus using + and - in cases where it's faster,
> right? (constant time complexity when possible, linear
> otherwise).
That would be best.
> Iterators being only one example of types that fulfill
> these requirements.
>
> Providing the implementation for next/prior in the documentation might
> be sufficient for the one-argument-version, but for the two argument
> version it's quite hard to help getting the implementation bug-free if
> I don't know what you intended. Can you write down original intent,
> please?
Well, you came up with the 2-arg version. I can only say that the
original intent of the 1-arg versions was to operate on anything
supporting prefix ++/--, respectively. If the 2-arg version won't do
that, I guess we should change the name.
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.
-- 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