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

From: Dave Dribin (dave-ml_at_[hidden])
Date: 2006-07-25 17:28:27

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.

> 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.

> 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?  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.

>> 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".)

Yes, I would agree.  As far as possible, but not at the expense of  
legitimate and useful use cases.  An endian class library, that could  
be used in unions, would have saved me a good chunk of time on a  
recent client project.

I keep re-reading the documentation, and nowhere does it explain that  
interchangeability with integer types is a key requirement.  It talks  
about providing "integer-like byte-holder binary types with explicit  
control over byte order, value type, size, and alignment."  It talks  
about "use cases almost always involve I/O, either via files or  
network connections."  Unions are not uncommon in these situations.   
In fact, the example at the end gives a structure representing a file  
format.  Again, it is not at all uncommon to have structures that  
represent file formats that require unions.

Even one of the FAQ questions talks about why operators are are  
provided at all, since that isn't really the prime feature of these  
classes.  Basically, they are nice to have to make code more  
readable.  And I agree with that, so long as reducing clutter doesn't  
inhibit some real-world use cases.  Removing constructors makes only  
a small fraction of uses cases more wordy.

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.

-Dave