Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 11:12:46AM +0200, Lars Gullik Bjønnes wrote:
>> | Debugging suggests that we have a problem with cursors accessing not
>> | existing paragraphs. Looking at the code this might well be possible: If
>> | the paragraph list is changed heavily (say assigned to) we invalidate
>> | all iterators to it, most notably those hidden in the Cursors belonging
>> | to the InsetText's LyXText. For smaller changes (say erasing of one
>> | element), we invalidate only a few 'unlucky' iterators. Some times it
>> | happens to work.
>>
>> But won't this be the case with offsets as well? Only get silent
>> failure instead of crash, but the offset is still invalid.
>
| No. See below.
>
>> | There are several places in the code where this is not taken care of
>> | (most places actually), and frankly, I do neither want to figure out
>> | where all of these places are nor do I want to add glue code 'just to
>> | make it work' as long as there 'automatic' solutions.
>> >
>> | One 'automatic' solution (and the simplest I can think of) is to use
>> | offsets instead of iterators. These are stable, can be copied around
>> | at will and checked for validity for each access if necessary. There is
>> | neither glue code needed, and there is no need to hunt down and check
>> | all occurences in the 'user code'.
>>
>> You cannot really check an offset for validity (except in a very few
>> special cases). An offset is almost always "valid" even if it points
>> to the wrong place.
>
| I can in some case, which happen to be most cases here: Most accesses go
| through LyXText::doSomething() (getPar() for instance).
>
| In these cases, we have access to the offset _and_ the paragraph list and
| can check e.g. for 0 <= offset < paragraph.size().
This is the special case I mentioned.
You only check that the offset does not go off the end of the
paragraphlist/paragraph.
| Moreover, we have now an 'uninitialized' value (-1, set in LyXCursor's
| default constructor) on which we can assert whenever we need a 'valid'
| cursor.
I wonder... would a more explicit "uninitialized" value be in order?
boost::optional<offset_t>
| The current problem is not just that the structures are broken, but that
| we are not able to tell when this happens. Early asserts would help
| much.
Sure.
--
Lgb
