Re: [boost] [GIL] locator and cached_location_t

Subject: Re: [boost] [GIL] locator and cached_location_t
From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2010-12-17 01:12:42

On Dec 16, 2010, at 1:24 AM, <fabien.castan_at_[hidden]<mailto:fabien.castan_at_[hidden]>> <fabien.castan_at_[hidden]<mailto:fabien.castan_at_[hidden]>> wrote:

Ok for my first question. I understand the idea of not polluting the "image_view" class with something specific that can not be used in all cases.

But what about the second question: adding 2 functions inside the locator class.
The idea is to allows to get a locator or an iterator from a locator using cached_location ?
Currently we have an operator[] inside the locator class which takes a cached_location_t and returns a pixel.
It seems interesting to add x_at(const cached_location_t&) and xy_at(const cached_location_t&) versions which returns respectively iterator or locator, isn't it ?

I don't see a particular reason why we shouldn't have such methods, other than polluting the interface with rarely used methods. It is not immediately obvious to me why you would use this.
Cached location is meant to be used as a quick way to get to neighborhood pixels if you need to read or write a neighboring location frequently relative to a given locator.
But the only reason you would prefer an iterator instead is if you want to move it. I cannot think of a case where you want to construct millions of iterators at fixed locations relative to a current locator... Can you explain why you would need such functionality?

Lubomir