[GIL] Default constructing pixels??
I am used to explicitly invoking the default constructor to initialize values to 'zero', but that does not seem to work with GIL. In the following code: template<class View> void do_something(View const& img){ typedef typename View::value_type pixel_type; pixel_type black = pixel_type(); //I expect zero, I guess this may not always be black... //..... } The value held in 'black' turns out to be 205 (I think it is acting like uninitialized stack data). Is this the intended behavior? I have a slew of code that used to work this way and somehow now it does not - did this behavior change recently? In the meantime I just made a struct named black with a typecast operator enabled for gil pixels. -- John
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.
#include
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
participants (2)
-
Christian Henning -
John Femiani