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.