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

From: Dave Dribin (dave-ml_at_[hidden])
Date: 2006-07-20 17:51:55

On Jul 20, 2006, at 4:17 PM, loufoque wrote:
> Dave Dribin wrote :
>> I see two issues with the library as  of 0.5.  First, the endian  
>> classes
>> cannot be used in unions.  And, second the classes cannot be used in
>> variable argument lists.
>
> How is that a problem ?
> Those are old C features that should be avoided.

Maybe I'm misunderstanding the use case of the endian library, but I  
can see these classes being used to read and write binary file  
formats and network messages.  Sometimes these things use unions.   
It's not necessarily an old C feature.  It's genuinely useful to have  
two fields map to the same memory location for some protocols or file  
formats.

The use case I gave on Boost-users was I had to port code to read and  
write Apple's HFS+ file system.  Apple was kind enough to provide  
structures (and unions) to access the low-level data:

   <http://darwinsource.opendarwin.org/10.4.6.ppc/xnu-792.6.70/bsd/ 
hfs/hfs_format.h>

Of course, when I ported code that used this header from PowerPC to  
Intel, the endian was wrong.  I basically wrote my own C++ classes,  
very similar to the Boost ones, to help hide the byte swapping  
ugliness which was needed.  With these classes, I was able to replace  
all uses of u_int32_t with ubig4_t in the header file.  Then, all my  
code that accessed these structures was instantly portable to Intel  
with very little code changes.  It was pretty remarkable, actually.

> Using an ugly interface just to make it a POD type is a bad idea IMO.

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

-Dave