Fernando Cacciola wrote:
Lubomir Bourdev wrote:
Yes, values have a default constructor and a proper copy constructor. References do not. As stated in the concept definitions.
Just for the record, references do have copy constructors. Is just that they are shallow.
That's what I meant by not having proper copy constructor.
Note also that "red", "green", etc. are not part of the pixel concept. Therefore you should not use the channel names directly in generic code.
Ha OK. But x,y are part of the Point concept rigtht?
Yes, as of now.
Thus, pixel references (for both types of pixels) yields "pixel<>" objects as a closest match to a "pixel rvalue", even though in the case of a planar pixel such object is really a deep copy of the pixels color.
In the case of a planar pixel we also use the same object for rvalue and lvalue - the planar reference. It is not a deep copy of the pixel's color (it contains references to each channel), but it is convertible to a deep copy.
-------------------------------------------------------------- ----------------
If all that is correct, or mostly correct, then I would suggest:
Yes your description was correct.
(1) rename the pixel<> class as color<>. (2) rename the planar_ptr<> class as planar_pixel_iterator<> (3) rename the planar_ref<> class as planar_pixel_handle<>
I am hesitating to do (1). Using color is very strange when inside the image. Color iterators? Looking at several other libraries I see the terms pixel, pixel iterators, used frequently... (2) is a good idea. We don't use the class directly so it is not a big deal to have a longer name. (3) Good suggestion, but maybe we could change to planar_pixel_reference. I don't want to introduce the term "handle". Reference is already used in this context, for example "reference proxy" object is a common term. Thanks for your suggestions, Lubomir