2013/1/28 Christian Henning <chhenning@gmail.com>
Hi,
On Mon, Jan 28, 2013 at 9:53 AM, TONGARI <tongari95@gmail.com> wrote:
Hi there,
I'm curious of why gil::get_color(pixel, tag) is defined that way. Any need to take the tag value?
If not, I'd prefer gil::get_color<Tag>(pixel) or just gil::get<Tag>(pixel) or even Tag::get(pixel).
You can use the "at_c" function.
rgb8_pixel_t p( 10, 20, 30); unsigned char c = at_c<0>( p ); assert( c == 10 );
That doesn't really answer my question... I just wonder the rationale for taking the tag value. I know there are at_c/semantic_at_c things, but they don't fit my need. Those functions are useful if I'm an end-user who knows the exact format, but I'm writing a 2D graphics lib building on GIL that intends to support all types the user gave, so index means nothing here, I must get the component by tag, thus get<red_t>(c) won't compile if the user gives cmyk.
And if possible, I hope GIL would just make pixel a Fusion sequence.
I'm very interested in ideas to improve gil! Since I'm not familiar with a fusion sequence could you elaborate a little further.
I imagine it to be an Associative Sequence in Fusion (naturally or adapted). So I can just use the algorithms provided by Fusion, which seem to overwhelm the static_xxxs in GIL. Thanks.