Re: [gtkmm] Gtkmm-forge digest, Vol 1 #187 - 15 msgs

[Carl Nygard <cjnygard fast net>]

On Fri, 2002-08-09 at 16:40, Martin Schulze wrote:
> Am 09.08.2002 21:30 schrieb(en) Carl Nygard:
> > On Fri, 2002-08-09 at 15:01, gtkmm-forge-request lists sourceforge net
> > wrote:
> > 
> > > Changed by murrayc usa net 
> > >
> > > --- shadow/90148	Thu Aug  8 16:01:40 2002
> > > +++ shadow/90148.tmp.1203	Fri Aug  9 02:53:54 2002
> > > @@ -72,6 +72,17 @@
> > >  iterator&, const iterator&)'! Shouldn't we just get rid of it?
> > >  The same goes for delete_interactive_text() but here we have an
> > >  additional problem: shall we really discard the boolean return value
> > >  (which shows whether text was actually deleted)? Is there some kind of
> > >  'invalid' or 'eof' iterator that we could return in the case that no
> > >  text was deleted?
> > > +
> > > +------- Additional Comments From murrayc usa net  2002-08-09 02:53
> > -------
> > > +Yes, if both the start and end would be equal after the method has
> > > +finished then there is no need to return both as well as the return
> > > +iterator.
> > > +
> > > +Maybe you could use end() to show that the deletion has not happened.
> > > +I don't think that end() would ever be the real "location where text
> > > +was deleted." That's what find() would use to show that something was
> > > +not found. Or maybe you could add an overload that takes a bool&
> > > +parameter.
> > >
> > 
> > If one calls delete_text(myIter, end()), shouldn't this work fine, and
> > also return end() as the iterator?  In this case it would signify proper
> > deletion of text from myIter to the end of the buffer.
> 
> Can anyone acknowledge this? In this case we'd have to include a bool& in
> the parameter list of delete_interactive_text().

I can't acknowledge.  I'm just looking at it from the pure STL iterator
perspective.


Regards,
Carl