On 6/9/06, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
Are you implementing the big_endian<T> class as holding a member of type T? If you do (that's the most logical way, I think), then it sounds most strange to me. Is it just one compiler that's causing problems? Have you tried on more than one compiler?
Yes, it's holding it as a member. I've tried it (with the same results) in g++ 3.3.6, 3.4.6, and 4.1.1. I just installed icc to try it with that, but I think there's a library mismatch or something with the rest of my system as I can't even get hello world to compile with it. I think it might just be a matter of the compiler getting lost in all the templates and being careful. When I try a simple test case with basically the same hierarchy and members it works fine: template <typename T, typename U> struct operators2 {}; template <typename T, typename U> struct int_wrapper_operators2 {}; template <size_t n_bits> struct exact : int_wrapper_operators2< exact<n_bits>, int > { char a[n_bits/8]; }; template <typename T> struct big_endian : int_wrapper_operators2< big_endian<T>, int > { T val; }; Resulting in ( sizeof( operators2<float,int> ) ) = 1 ( sizeof( int_wrapper_operators2<float,int> ) ) = 1 ( sizeof( long ) ) = 4 ( sizeof( big_endian<long> ) ) = 4 ( sizeof( exact<24> ) ) = 3 ( sizeof( big_endian< exact<24> > ) ) = 3 Is there possible a class deep down in operators<T,U> that is only templated on U? If there is, maybe the compile doesn't want to put the instance from integer_cover_operators< exact<24>, int > and integer_cover_operators< big_endian<exact<24> >, int > at the same address. I've also attached the problematic code as well, in the hopes that someone can find the problem or see whether it's gcc-specific. ( The integer_cover_operators.hpp is the same as Beman's, with the exception of using boost::operators<T,IntegerType> instead of boost::operators<T>. This solved an issue where std::numeric_limits< boost::exact<24> >::min()-1 was ambiguous. ) ~ Scott McMurray