Andre Poenitz wrote:
> On Sat, Mar 27, 2004 at 04:14:48PM +0100, Alfredo Braunstein wrote:
>> This is the merge of paritertator with dociterator, allowing pariterator
>> to go into math-text insets etc.
>>
>> + const correctness of InsetText::paragraphs
>> + 12 files changed, 145 insertions(+), 358 deletions(-)
>
>
> +void DocumentIterator::forwardPar()
> +{
> + while (true) {
> + size_t old_depth = depth();
> + idx_type old_idx = idx();
> + par_type old_par = par();
> +
> + forwardPos();
> +
> + if (empty())
> + break;
> +
> + if (text()) {
> + if (depth() > old_depth)
> + break;
> + if (depth() == old_depth
> + && (old_idx != idx() || old_par != par()))
> + break;
> + }
> + }
> +}
>
> I would have simply checked for pos() == 0 && inTexted().
>
> Andre'
>
> PS:
>
> Paragraph * ParIterator::operator->() const
> {
> - return &plist()[positions_.back().pit];
> + return &text()->getPar(par());
> }
>
> I wonder whether a namining scheme 'pit' for paroffet_type/par_type
> (which consequenlty could be called 'pit_type') for variables and 'par'
> for 'Paragraph &' variables would make things more uniform
Completely agreed.
>> Things which are not so clean:
>>
>> - the use of a tmp InsetText in C&P (we should tackle this with C&P IU)
>
> We can live with that. Or use an Undo item. Or something new...
>
>> - the provided implementation of forwardPar (the other one was not
>> working) makes ParIterator to be as "slow" as PosIterator.
>
> This probably will show up in the profiler somewhere. However,
> PosIterator gained a lot performance-wise from the ParagraphList
> change to a std::vector.
It may be (but it was already quite fast: unnoticeable in Userguide20 was
already before the switch).
>> - the fact that DocIterator doesn't have yet a
>> correct past-the-end position.
>
> It has. 'DocIterator()' _is_ the past-the-end position (in both
> directions btw). So it basically has the same interface as a
> i/ostream(::iterator) nowadays. I emphasized this a bit by providing
This setup doesn't allow comming back from the end position (and among other
things, cannot satisfy bidi iterator requirements)
> operator!() and operator void*() which basically test for empty() and
> are quite a bit faster than the 'usual' comparison against an explicit
> end iterator.
Oh come on, there's basically no time penalty in testing one single slice
(which is what I think the past-the-end iterator should be)...
Alfredo
