Re: [Boost-users] [GIL] Warnings when compiling items in channel_algorithms.hpp

Subject: Re: [Boost-users] [GIL] Warnings when compiling items in channel_algorithms.hpp
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-06-23 12:42:58

Hi there,

On Mon, Jun 21, 2010 at 6:11 PM, Nathan Crookston
<nathan.crookston_at_[hidden]> wrote:
> Hi Christian,
>
> Thanks for looking over my patch.  With a minor amount of tweaking of
> your code and my sample program, I was able to compile both my sample
> program and my reasonably extensive work code.
>
> The only difference between what you suggested and what I'm posting is
> the addition of some explicit construction calls:

I'm sorry I cannot make out your addition of some explicit constructor
calls. Did you send the correct patch snippet? Could we just post the
code without the patch syntax? I don't use patch.

>
> My sample program required the following modification:
>
> FROM:
>  template <>
>   struct unsigned_integral_max_value<bits14>
>     : public mpl::integral_c<uint32_t,bits14_max_val> {};
> TO:
>
>  template <>
>   struct unsigned_integral_max_value<bits14>
>     : public mpl::integral_c<uint16_t,bits14_max_val> {};
>
> This makes the specialization of unsigned_integral_max_value different
> from the others in channel_algorithm.hpp -- they use uint32_t and
> uintmax_t, even for 8 and 16 bit types.  This appears to be
> intentional, as changing them to match their arguments results in a
> compile error (and many tricky const initialization problems).  This
> makes me wonder if the unsigned_integral_max_value<>::value_type was
> intended to be used that way.

I believe this is intentional. Having all using uint32_t would
eliminate useless casting which could be a performance problem. But
when using 64bit unsigned integer we are back to casting world. This
might be a grey area for gil and a next version should be easier to
use.

>
> I wonder if there's value in a metafunction that returns the type we
> expect to construct our channel from (similar to the suggested
> base_channel).  This isn't a critical issue for me, however, as your
> suggestions are working well for me now.

Honestly, I'm not a aware of such a meta-function. A next gil version
should take care of these issues.

I'll do some more testing before I check in this change.

Thanks,
Christian