Andre Poenitz wrote: > 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.
Why do you need that kind of stability? [only Undo, and possibly persistent saveable cursor positions come to my mind. But they can be treated separately] I still don't see when exactly do you actually *use* the offset (except ugh... something like "DocIterator::reUpdateCaches()"?). So it seems to me that the optimal thing would be to have two separate structures: one only with offsets (basically for undo) and the other only with pits for iterating, and methods to switch from one to the other. I just don't see the point of having both in the same structure. > (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? I bet that much of it won't work, because we use the fact that pits are stable under removal/insert of other elements too much. Alfredo
