On Jul 20, 2006, at 4:17 PM, loufoque wrote:
[snip]
What's ugly? The ::init()? It's not *that* ugly. And it makes the library more useful. What's the use case for requiring elegant initializers? I don't see many people doing something like:
big4_t x = 42;
What about the use of endian objects where one would expect raw integral objects? Such use includes template<typename DestT, typename SourceT> DestT make_double(SourceT val) { return 2 * val; } big4_t doubleVal = make_double<big4_t>(21); The generic code need not even deal with arithmetic at all, such as in vector<int> int_vect; ... vector<big4_t> big4_vect(int_vect.begin(), int_vect.end()); Since we do not have the luxury of two user-defined conversions in the chain from 'int' to 'endian<...>', which would allow us to write an intermediate type with both an 'int' constructor and an 'endian' operator, we have to choose: unions (and other pure POD scenarios) or conversion from raw integral objects. I think a wise decision was made in the choosing the latter.
What good is a single big-endian variable on the stack? I see far more use cases for these classes in structs and unions, and then writing them out a file descriptor.
But we also want it to be interchangeable - as far as possible - with integers in generic code (whether templates or "copy-and-pasting".) /David