On Wed, Mar 10, 2004 at 09:05:40AM +0100, Alfredo Braunstein wrote: > > The obvious idea is to use and/or cache some ParagraphList iterator > > instead of the par offset... > > > > Maybe we've to use both. In fact, it's almost the same as with the > > 'inset_' member: This is just a form of a cache itself. > > Right. > > > So we'd remove the 'paroffset_type & CursorSlice::par()' member and > > provide 'elementary' accessors > > > > setFirstPar() > > setLastPar() > > incrementPar() > > > > etc. Doesn't sound overly complicated... > > Can you explain a bit more? You store both a ParagraphList::iterator pit_ > and the offset. Then you use only pit_ for iterating?
No, both have to be kept in sync. This should be O(1) though for standard operations like initialization, one up, one down etc. > Doesn't that defeat the purpose of having the offset at all Partially, yes. > (hum... what was it again)? (1) A 'stable' iterator not dependent on the location of some random chunk in memory (aka 'pointer'). Ok, that was already defeated by having the inset_ cache, but my original intention wsa to get rid of that. (2) #include independence of the paragraph stuff When I think about it: Has anybody ever tried to use a std::vector<> (-like container) instead of a std::list<> as text container? The critical operations are, of course, inserting and removing a paragraph. This would mean shifting around lots of stuff but it can't be much slower than the initial rebreak, can it? Andre'
