On 15 February 2013 22:14, Christian Henning <chhenning@gmail.com> wrote:
Mateusz Loskot <mateusz@loskot.net> wrote:
3) scanline_read_iterator is an input iterator, do you also plan output one too?
Not before the release. But logically I don't think there is much interest. What do you think?
I don't know if there is any interest, but my question was triggered by the symmetry pursuit. It could make a logical addition. Just asking, not expecting it
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.
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?
Finally, question not related directly to iterators, but to GIL interface in general. GIL functions require to cast various objects to pointers or iterators, like in the example above:
(image_t::view_t::x_iterator) buffer
IMO, it's weak link and it's the point where users mostly get into trouble with GIL. Would it be possible to at least document rules for such conversions?
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*?
Shortly, would it be possible to describe systematic way of deciding about these conversions in GIL?
What conversion? For instance there is no conversion when dealing with "compatible" images, like rgb and bgr. Conversion takes place when changing the color space.
I meant conversions by casting, a type conversion within C++ domain. Not color/channel/pixel conversions, not raster domain. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net