On Wednesday, July 04, 2012 22:26:16 RivenTheMage wrote: > > Currently I think that idea was very bad, given that it would > > be difficult to find all ranges which invalidate previous front > > value on popFront. > > It seems, consumeFront() is attempt to implement a forward > iterator on top of a range. Maybe the problem is mixing up two > different abstractions.
No. popFront iterates already. Iterators would have essentially the same problem. The problem is that while in most cases, separating getting the element referred to by the iterator (or the front of the range) separately from iterating is more efficient than having the iterator return an element when you iterate it, in some cases (strings in particular), it's more efficient to have the element returned when the iterator iterates. That's because the element is calculated, and there's no way to cache the result. Now, most ranges and iterators wouldn't have this problem, because they could have front cache the result such that if it were called before popFront, it wouldn't have to then do the calculation again (though having a function which did both in a single operation would still save you _some_ performance because you wouldn't have to cache anything or check whether anything had been cached). But strings can't do that, because they're arrays. So, it's not an issue of iterators vs ranges. It's 2 things 1. The fact that strings are arrays eliminates their ability to cache any calculations. 2. _Any_ range (or iterator) which can calculate its front and pop it more efficiently as one operation than it can separately is going to be more efficient if it can be operated on with that single function (consumeFront in this case) than it will be by using two (front and popFront in this case) - even if it can cache the necessary calculations, because that caching costs something. - Jonathan M Davis
