Daniel Frey <daniel.frey@aixigo.de> writes:
David Abrahams wrote:
Daniel Frey <daniel.frey@aixigo.de> 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