Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2010-05-28 02:03:41

I'm just commenting for emphasis, no disagreements.
Below...

On Thu, May 27, 2010 at 10:29 AM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> vicente.botet wrote:
>> Rob Stewart wrote:
>>
>> > I don't see any type safety problems in my original or
>> >  hybrid APIs.
>>
>> The problem is that we don't know the endiannes of the types
>> int32_t or long. This depends on the operation you have
>> performed on your code. E.g.
>
> Endianness is not part of the type, so referring to type safety mislead me.
>
>>    int32_t wire(/* from wire */);
>>    long l1;
>>    long l2;
>>    to_big_endian(l1, l2);
>>    to_big_endian(l2, wire);
>>

Yes, the point here is that 'wire' isn't really an int, is it?  At
least not a useful one (at least when the machine's order doesn't
match the wire).
Thus they should be distinct types.

>> With the typed endians this is not possible.
>>    big32_t wire(/* from wire */);
>>    long l1;
>>    long l2;
>>    l2=l1; // no endian change as both are native
>>    wire=l2; // conversion to big from native.
>
> That's a sensible concern and reason to provide such types (without the operators) along with the less safe functions.
>

Yep, I think it would be great if we could always use big32_t, etc.
But you know there will be times when you are handed predefined
objects with ints (but not really) in them, etc.

So less safe functions, including in-place functions, will be needed.

And I also agree that the operators should be avoided.

Tony