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