|
Boost Users : |
From: David Abrahams (dave_at_[hidden])
Date: 2006-07-03 08:45:58
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.
> so you save exactly one instantiation saved, which is at most 50%.
>
> But again, if you say that it's important, then I'll accept it.
I'm actually not making any such claims.
> 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.
> 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.
> And also all sequences should take advantage of this, and actually
> specialize front and back to save this instantiation.
>
> The other option is to declare that an extra single instantiation s not
> that bad, not require front/back, and leave all possible optimizations
> to begin/end. The default front/back will work fine.
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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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