Hi Mateusz,
b) reader_t::begin(buffer) could be added, for convenience
Mhmm, you think so?
With this suggestion, I hoped to provoke some wider discussion about such interface. Not very common prototype of begin() function, is it? It seems convenient as it hides the "boring" boilerplate, analogously to std::make_pair and other such functions.
Could you give me some prototype code?
c) Any particular reason you don't use result of the iterator deference directly?
(image_t::view_t::x_iterator) *it
I don't need to in my example. The dereference operator returns the buffer which we already have access to.
Yes, I understand that, but IMHO it makes the purpose of this iterator obscure. You know the internal details of the iterator, so you use the fact that the iterator simply advances the buffer pointer. You simply use the iteration side effect here. But, I think most of users who don't dig how this iterator is implemented, will wonder why the result of derefence is not used.
I think, discoverability is important and most users will try to apply the knowledge about iterators they already have got. Is there similar analogy to this in std:: or other commonly used iterators that I've missed?
I don't wanna create an "obscure" iterator and try my best to make sure it's easy to use and also to behave as expected. I know I'm not an expert in the field but I'm here to learn. Anyway, there are two thing I need to accomplish when reading image and the common iterator interface doesn't seem to support it naturally: 1) read a scanline, via dereference operator 2) don't read the scanline but still move the internal scanline counter, via ++operator I'm open to better ideas!
I agree that gil's documentation is somewhat lacking and that the learning curve is quite steep. On the other side gil does a lot behind the scene and sometimes I find it amazing that it just works!
Now I cannot really comment on the reasoning why the initial developers designed parts the way they did. But for x_iterator I believe they did it well. Somehow you have to tell interleaved_view what kind of view you will create. It's also very handy when dealing for instance, with rgb and bgr images and generic algorithms.
I believe these sequence of posts exchanged during the GIL review explains it quite well, with most important part from the third link being
"We do indeed cast the user-supplied channel* to pixel_t*, so that we can construct an interleaved view of the user-supplied memory. "
http://lists.boost.org/Archives/boost/2006/10/112053.php http://lists.boost.org/Archives/boost/2006/10/112059.php http://lists.boost.org/Archives/boost/2006/10/112064.php
but...
What are the basic steps to decide on particular conversion of image buffer or view to certain type of pointer/iterator/location.
??? You lost me here.
Simple question users frequently wonder about (mostly on SO, AFAIR):
How do I decide in particular case between casting to x_iterator or rgb8_pixel_t*?
For rgb8_image_t the x_iterator is rgb8_pixel_t*. x_iterator you use when you don't know the image_t or view_t during compile time. Does that make sense? Regards, Christian