Hi John, I have asked Lubomir about a year back about that "feature". He mentioned performance reasons, which I take is the right answer.
I'm sure you know about it. But for the sake of introducing gil to the boost community, here is a little code.
<snip> Thanks Christian, Somehow I thought it was working once but perhaps I had been constructing the gray8 pixels by passing a zero to the constructor. Anyhow it was an unsafe thing for me to do. I was just surprised today when I saw that pixels were not being zero-initialized.
Question, can I use BOOST_FOR_EACH to get rid of the function object?
I don't know if Homogeneous pixels are a boost range, but the Heterogeneous ones can not be (They could maybe satisfy Boost.Fusion concepts though).
On the other hand there might be a case for having a boolean as a parameter to the pixel constructor determining if the channels should be initialized or not.
Or maybe something like this: struct uninitialized {}; gray8_pixel_t pixel; //Sets value to black, as one would expect gray8_pixel_t pixel(uninitialized()); //Does not construct members That way people who expect predictable behavior from the default constructor get it, and people who want to optimize should be able do so with no runtime check (overloading causes a different constructor to be called). That is a lot like what I am doing, except that since I don't want to modify boost code I am using typecast operators as follows: struct black{ operator gray8_pixel_t (){ return gray8_pixel_t(0); } // I think I could have written a templatized // operator, but I did not. }; //later, in generic code where PixelType happens to be gray8_pixel_t: PixelType &pixel = black(); I think I could have used the GIL color converting functions to make a template typecast operator but I did not do that (yet). In my implementation I am only instantiating my attempted generic function with gray8 pixels so far. -- John Femiani