Boost logo

Boost Users :

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-07-03 10:05:00


David Abrahams wrote:
> Yuval Ronen <ronen_yuval_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> Yuval Ronen <ronen_yuval_at_[hidden]> writes:
>>>
>>>> David Abrahams wrote:
>>>>> 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
>>>> 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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net