Re: [boost] [endian] Comments on Endian 0.5

From: David Bergman (David.Bergman_at_[hidden])
Date: 2006-07-25 23:56:18

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