David Abrahams wrote:
Yuval Ronen
writes: David Abrahams wrote:
Yuval Ronen
writes: The default version of front always takes at least two instantiations (begin<...> and deref<...>). If you can do front in one instantiation and you want the optimization, you'd better specialize it. If this single instantiation you save is important (which sounds to me
David Abrahams wrote: like too small a thing to mess with, but if you claim otherwise, I'll take your word for it), It's at least a 50% savings, and quite possibly more than 50%. It's at most 50%, not at least. Remember that I compare specializing 'front' to using the default 'front' + specializing 'begin'. Any optimization you put in 'front' you can also put in 'begin',
No. Producing an iterator can be arbitrarily more expensive than producing the first element, and can't necessarily be done with a single specialization.
OK, I didn't know that producing an iterator can be arbitrarily more expensive than producing the first element (while still maintaining constant time). That's definitely new information for me, and I'll have to take it into account.
so you save exactly one instantiation saved, which is at most 50%.
This sentence of mine is obviously wrong, in light of this new information.
Where I was going (or was trying to go - we'll see if I'll actually get there) is to show that there is a contradiction between two things. The first is the claim that a single instantiation is worth saving. The second is Forward Sequence requiring 'front' and not 'back'.
You'll never get there with me; they're unrelated questions.
I was trying to show that they are in fact related, unsuccessfully.
If we're that much into saving, then it should require back for the same reason as it requires front.
Sorry, I'll never agree to that. It's like saying that all iterators need to be bidirectional just because they should be incrementable.
I disagree with the validity of the comparison. It's not the same thing. Supplying 'back', in order to allow for sequences to specialize and optimize it (to save producing an iterator, which is "arbitrarily more expensive"), is not comparable to the incrementable/bidirectional iterators issue. The latter is about capabilities, while the former is about performance improvement possibilities.
That's one other option. Another option is just to work with the concepts as they are and stop trying to convince us they're ill-conceived. What's wrong with that one? I don't mean to be facetious, but you seem to be grasping at straws to show that there's something wrong here, but I don't see what major problems the status quo is causing.
I was hoping to get to the bottom of this, to fully understand what's going on, and why, to convince or be convinced. However, if you are unwilling to continue this discussion, then, well, you have every right to do so. We'll just go our separate ways, each maintaining his original opinion, one of us (me) is wrong.