Subject: Re: [boost] [GIL] kth_channel_view
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-08-05 11:57:36
On Thu, Aug 5, 2010 at 11:02 AM, <fabien.castan_at_[hidden]> wrote:
> Yes, it works fine without const.
> I used const automatically because I don't write in my image but I don't think it changes something.
> So without seems to be better because it's not the correct way to deal with const inside gil.
I would argue that there is a bug in gil since const_view doesn't work
with kth_channel_view_type. Maybe we need to have
const_kth_channel_view_type or something?
> I don't know how we can declare a parameter to be a const view...
> For example a simple function that takes an image v and returns if it contains a pixel p:
> template<class MyGilConstView>
> bool f( const MyGilConstView& v, const MyGilConstView::value_type& p );
> This function can't garantee that it doesn't modify the image v and the pixel p.
The following gives me a compiler error, as expected.
template< typename ConstView >
void foo( ConstView v )
typedef typename ConstView::value_type pixel_t;
*v.at( 0, 0 ) = pixel_t();
int _tmain(int argc, _TCHAR* argv)
foo( const_view( img ) );
The thing is that you cannot guarantee ConstView to be a const_view,
meaning rgb8c_view_t, or etc... . Using concepts would help here, I
> I can create a const view at the begining of the function, to get this garantee, like this:
> typedef MyGilConstView::const_t MyGilReallyConstView;
> typedef MyGilReallyConstView::value_type MyGilReallyConstPixel; // as there is no const_t typedef in pixel type...
> MyGilReallyConstView cv = v;
> MyGilReallyConstPixel cp = p;
> Is it correct ?
> Is there a better way to do it ?
I concepts would help. I don't have a better idea right now other than
that you and I have to be very careful when passing const_views as a
> PS: maybe a "typedef value_type pixel_t" inside the view class can be a good thing for readability ?
I believe the name value_type comes from STL. I would prefer pixel_t
myself, as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk