On Thu, Mar 11, 2004 at 11:38:16AM +0100, Alfredo Braunstein wrote: > > (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]
Well, I did not want to have too many classes doing basically the same job. But it looks as though we need at least 'stable iterator for storing positions' and 'fast iterators for actual iteration'. > 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. You are probably right. It just takes me some time to get used to new ideas ;-} > I just don't see the point of having both in the same structure. Well, it'd be nice if it works out well. Alas, it doesn't. > > (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. Yes, but with a vector + offset approach we could recreate pits in O(1) (i.e. basically _never_ need to use them except for interfacing STL algorithms etc...) Andre'
