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