
Hi there,
On Mon, Jun 21, 2010 at 6:11 PM, Nathan Crookston
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
{}; TO: template <> struct unsigned_integral_max_value<bits14> : public mpl::integral_c
{}; 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