On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | When I think about it: Has anybody ever tried to use a std::vector<>
> | (-like container) instead of a std::list<> as text container?
>
> You loose the fast undo/paste stuff. since you will need to
> reallocate... with std::list a splice is done.
[Well, 'could be done', right now it's an insert. Lazy me...]
I know. However, ideally there will be at most one of these per user
interaction and I have the suspicion that we could afford this.
In any case, I am not going to implement this, this was merely a
genuine 'What might happen if...' question...
> What are the benefits you see with a vector?
The 'stable iterator' thing independent of memory position. List
iterators are (reasonably) stable, but they basically point to
somewhere. So they can't be stored externally.
And they are not 'totally stable'. So e.g. storing an iterator to some
place within a footnote, copy&paste the footnote to somewhere else
(directly or via undo...) most likely invalidates the iterator.
If you keep it as integer offset it _is_ 'totally stable'.
Right now we know due to Alfredo's detective work that having only
integer offsets is not fast enough if we want to use them to iterate
over the main lyx text.
So possible solutions are:
(1) keep the current scheme of specialized but limited iterators
(ParIterator e.g. does not descend to the nowadays real text
within a mathed mbox)
(2) use an ParagraphList based iterator and add math capabilities
(lots of work...)
(3) use a DocumentIterator based iterator and make it fast
by adding some ParagraphList::iterator 'cache'
(4) use a DocumentIterator based iterator and make it fast
by changing the underlying container to deque/vector
I am currently leaning towards something close to (3), but was
loudly pondering (4). (1) is certainly an option, but not 'nice'.
(2) is nothing I'd tackle voluntarily.
There might be other solutions I am not aware of.
Andre'
