[Insight-developers] itkImageConstIteratorWithIndex.h
Mark Foskey
mark_foskey@unc.edu
Thu, 24 Apr 2003 10:07:09 -0400
Actually, I had already tried Jim's suggestion and observed that it
broke the tests before sending my original message. I should have
perhaps given more detail.
On the one hand, situations where you actually want to test whether
you're *on* the first or last element are rare, as you observe. But,
on the other hand, I think the current terminology is sure to create
consternation.
It seems like we have three options:
1. Leave it as is, but document the tests to indicate that they don't
quite mean what their names might suggest (but instead they tell you
what you're more likely to need to know),
2. Bite the bullet and change the names, along with all the code that
uses them. (We could have a PixelsRemaining() method, as Luis mentioned.)
3. Do like the STL and introduce reverse iterators. Then we would drop
the GoToEnd() and IsAtBegin() methods. This would probably break less
code than (2).
Luis Ibanez wrote:
>
> Not really,
>
> Since the purpose of these methods is to control
> the iterator's loops, both IsAtBegin() and IsAtEnd()
> should return past-the-end conditions. That is:
>
> IsAtBegin() should return = I'm before the begin
> ItAtEnd() should return = I'm past the end
>
> Just like the STL "end()" method.
> Unless we agree in not using these methods for
> controling loops anymore, and rely instead on a
> new method : bool PixelsRemaining() const
>
> However,... once we stop using IsAtBegin() and
> IsAtEnd() for controling loops... I don't see
> much use for these methods.
>
>
> Luis
>
>
> ---------------------------------
> Miller, James V (Research) wrote:
>
>> Luis,
>>
>> I think the IsAtBegin() and IsAtEnd() methods should always be able
>> to answer the questions of whether the iterator is at the first pixel
>> or one past the last pixel.
>> Couldn't the implementations of these methods be
>> /** Is the iterator at the beginning of the region? "Begin" is defined
>> * as the first pixel in the region. */ bool IsAtBegin(void) const
>> {
>> return (m_Position == m_Begin);
>> }
>>
>> /** Is the iterator at the end of the region? "End" is defined as one
>> * pixel past the last pixel of the region. */
>> bool IsAtEnd(void) const
>> {
>> return (m_Position == m_End);
>> }
>>
>>
>>
>>> -----Original Message-----
>>> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>>> Sent: Wednesday, April 23, 2003 8:41 PM
>>> To: Mark Foskey
>>> Cc: Joshua Cates; Miller, James V (Research);
>>> insight-developers@public.kitware.com
>>> Subject: Re: [Insight-developers] itkImageConstIteratorWithIndex.h
>>>
>>>
>>>
>>> Hi
>>>
>>> The current behavior of IsAtBegin() and ItAtEnd() is
>>> the right one. It shouldn't be changed. The issue is
>>> just to document their behavior.
>>>
>>> ----
>>>
>>> These two methods are intended to be the stopping conditions
>>> of while loops.
>>>
>>> IsAtBegin() is only used when the iterator is use as a
>>> reverse iterator like
>>>
>>>
>>> it.GoToEnd()
>>> while( !it.IsAtBegin() )
>>> {
>>> // do something here
>>> --it;
>>> }
>>>
>>> IsAtBegin() is not intended to be called in forward iteration.
>>>
>>> Same thing with IsAtEnd(), this method is not intended to be
>>> called after GoToEnd() but rahter after GoToBegin(). Like in
>>> the classical loop:
>>>
>>>
>>> it.GoToBegin()
>>> while( !it.IsAtEnd() )
>>> {
>>> // do something here
>>> ++it;
>>> }
>>>
>>> The two methods are just returning if there are still some
>>> pixels to be visited, not really if the iterator is at the
>>> end position.
>>>
>>> We could as well rename both methods as:
>>>
>>> it.PixelsRemaining()
>>>
>>> then,
>>> both loops will look similar:
>>>
>>>
>>> it.GoToBegin()
>>> while( it.PixelsRemaining() )
>>> {
>>> // do something here
>>> ++it;
>>> }
>>>
>>> and
>>>
>>>
>>>
>>> it.GoToEnd()
>>> while( it.PixelsRemaining() )
>>> {
>>> // do something here
>>> --it;
>>> }
>>>
>>>
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>> ------------------
>>>
>>> Mark Foskey wrote:
>>> > OK, I will investigate.
>>> >
>>> > Joshua Cates wrote:
>>> >
>>> >> I agree. This sounds like a bug to me.
>>> >>
>>> >> Josh.
>>> >>
>>> >>
>>> >> On Wed, 23 Apr 2003, Miller, James V (Research) wrote:
>>> >>
>>> >>
>>> >>> I think your examples should both print 1.
>>> >>>
>>> >>> So if possible (without breaking existing code), I would change the
>>> >>> code. A
>>> >>> call to IsAtBegin() should return true if it is called immediately
>>> >>> after a
>>> >>> GoToBegin(). Same for "end" versions.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>> -----Original Message-----
>>> >>>> From: Mark Foskey [mailto:mark_foskey@unc.edu]
>>> >>>> Sent: Wednesday, April 23, 2003 12:12 PM
>>> >>>> To: insight-developers@public.kitware.com
>>> >>>> Subject: [Insight-developers] itkImageConstIteratorWithIndex.h
>>> >>>>
>>> >>>>
>>> >>>> In itkImageConstIteratorWithIndex.h, both IsAtBegin() and IsAtEnd()
>>> >>>> return !m_Remaining. It appears that
>>> >>>>
>>> >>>> it.GoToBegin();
>>> >>>> std::cout << it.IsAtBegin() << std::endl;
>>> >>>>
>>> >>>> it.GoToEnd();
>>> >>>> std::cout << it.IsAtEnd() << std::endl;
>>> >>>>
>>> >>>> will both print 0. Do we at least want to document this behavior?
>>> >>>> I can imagine scenarios where you might want to test whether an
>>> >>>> iterator has been incremented since GoToBegin() was called,
>>> although
>>> >>>> I think they would be rare.
>>> >>>>
>>> >>>> --
>>> >>>> Mark Foskey (919) 843-5436 Computer-Aided Diagnosis and
>>> Display Lab
>>> >>>> mark_foskey@unc.edu Department of Radiology, CB 7515,
>>> UNC
>>> >>>> http://www.cs.unc.edu/~foskey Chapel Hill, NC 27599-7515
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Insight-developers mailing list
>>> >>>> Insight-developers@public.kitware.com
>>> >>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>> >>>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Insight-developers mailing list
>>> >>> Insight-developers@public.kitware.com
>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Insight-developers mailing list
>>> >> Insight-developers@public.kitware.com
>>> >> http://public.kitware.com/mailman/listinfo/insight-developers
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers@public.kitware.com
>> http://public.kitware.com/mailman/listinfo/insight-developers
>>
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
--
Mark Foskey (919) 843-5436 Computer-Aided Diagnosis and Display Lab
mark_foskey@unc.edu Department of Radiology, CB 7515, UNC
http://www.cs.unc.edu/~foskey Chapel Hill, NC 27599-7515