Re: opinion poll on text widget iterators



 
> > Also if you want to be really special you can place a class
> > pointer in the iterator.  The iterator could be made to 
> > then be abstract and skip items.  Thus you make an iterator
> > which jumps from picture to picture or char to char and 
> > all have the same size.
> > 
> 
> I have about 57 ways to move the iterator right now (next_char,
> next_word, end_of_line, next_line, up_line, down_line, find_backward,
> find_forward, etc.)
> 
> So next_pixmap is just another one of these. For C, I don't want
> different _types_ of iterator, because you want to be able to go
> forward a word, then down a line, then to the next pixmap, keeping the
> same iterator.

> For C++ you could simply have various subclasses where operator++
> called different iterator movement functions, right?

That is actually fine with me,  I can either have loads of 
iterator types or just make a supper iterator with special
methods not normally found like skip_forward_word().  
Just because we are trying to cast the problem to look
like C++ resources doesn't mean we can't expand an idea beyond
its STL intent.

> Note that my lines of text are thankfully not in a linked list, so
> there's no point in tail pointer caching for the text widget.

obviously, CList is a totally different matter because we
need to cache locations in the list.  But good to hear that 
I won't have to go through that pain.
    
> I don't _think_ this applies to the text widget - basically an
> embedded pixmap or widget is just a funky character, it can be deleted
> with backspace, you can insert before/after it, etc.
> 
> I guess you could have an iterator_assign() function that deletes
> whatever's at the current iterator and places new text or pixmap there
> instead.

That would be fine.  Under STL all you can do is assign a spot, but
you can achieve the same effect with your iterators by adding 
at the place and then removing the following item.  So if
you have the insert before and erase at equivalent there will
be no problem. 

--Karl




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]