David Dribin wrote:
On Jul 21, 2006, at 4:14 PM, David Bergman wrote:
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);
This doesn't seem to be a common use case for binary data structures used in I/O.
Ok, but *before* being output? The object might very well pass through some generic code.
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());
And this has a workaround by using a for loop.
I don't understand. One would need to use "::init", right? That is not exactly compatible with regular integer types - or most other types. I was refering to generic code which we cannot easily change, as well.
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.
I guess I disagree. With an assignment operator, most of the conversions from raw integral types are covered, and you can still use 'em in unions. If you still feel this way, would it be at least possible to add a #define to disable the constructors?
Yes, maybe.
This would allow the user of the library to choose what is important to them, rather than the library writer. We obviously can't support all use cases with the current limitations of the C++ language.
You are right. [snip]
Well, if I haven't convinced you by this point, hopefully at you'll at least consider using a #define to disable constructors for those people that *do* find a real-world use for such classes in unions.
I would probably not consider it, but it is not my choice :-) What I *would have* considered, though, is to have two templates: template<...> struct pod_endian { ... no constructor but all the endian logic ... } and template<...> struct endian : pod_endian { ... constructors and not much else ... } And have conversion operator to get an endian from a pod_endian. Additionally, I would probably use my embed_type proposal and get: template<.., typename IntType, ..> struct endian : embed_type<IntType, endian> { ... } using proper policies. /David