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 (Yes, I know,
it's mostly my fault...)
> 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.
> - 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
operator!() and operator void*() which basically test for empty() and
are quite a bit faster than the 'usual' comparison against an explicit
end iterator.
Andre'
