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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-07-31 23:13:14

"Dave Dribin" <dave-ml_at_[hidden]> wrote in message 
news:F773AA4D-E17B-4FB2-B872-116B17E7715B_at_dribin.org...
> Hello,
>
> I started a thread on Boost-users about the proposed endian library,
> but it's probably more suitable on the dev list.  Here's a link to
> the thread in the archives:
>
>   <http://lists.boost.org/boost-users/2006/07/20887.php>
>
> I see two issues with the library as  of 0.5.  First, the endian
> classes cannot be used in unions.

Yep, that's a problem. But it goes beyond union requirements - the class 
needs to be changed be POD's. The primary use is I/O, and that means they 
need to be memcpyable. And that means they must be POD's.

I know some have argued that both POD and non-POD versions should be 
supplied, but I don't want to depend on undefined behavior, which is what 
will happen with a non-POD endian class. Constructors can be added later if 
the committee decides to relax the POD requirements.

>  And, second the classes cannot be
> used in variable argument lists.  I'm attaching a patch to help
> resolve both of these issues.
>
> In order to be used in a union, a class must not have any
> constructors.  However, removing constructors breaks the following code:
>
>   big4_t x = 42;
>
> My solution was to provide a static init() method to help in these
> situations:
>
>   big4_t x = big_t::init(42);

Interesting. Of course you could have also written it like this:

    big4_t x; x=45;

> The second problem shows up using varargs.  For example, this will
> not compile:
>
>   printf("x = %d\n", x);
>
> The solution I came up with is to use operator() to get the native
> value:
>
>   printf("x = %d\n", x());

My old implementation also did that, but over time I came to feel it was too 
cryptic. I'd prefer to call the functon value() I think.

>
> In my patch, I've also added a check_unions() function to
> endian_test.cpp that tests the sizes of unions.

Thanks for spotting these problems. I fell stupid for no thinking the POD 
issue throught before this. My old interface was a POD - I guess I got 
seduced by the elegance of Darin's interface and wishful thinking about 
changing C++ to allow POD's to have constructors (except copy constructors).

--Beman