Re: [boost] [endian] endian flip and endian domain

Subject: Re: [boost] [endian] endian flip and endian domain
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2010-06-08 13:44:08

First of all, I think we are confusing each other somewhere in these
emails - I you, or you me, or both.  Which, as you mention later down,
does highlight the needs/problems.  So if I talk past your some of
your points, that might be why.  Somehow, even in the confusion, I
still think we are highlighting worthwhile points.

On Tue, Jun 8, 2010 at 12:59 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Gottlob Frege wrote:
>> On Tue, Jun 8, 2010 at 11:52 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> > Gottlob Frege wrote:
>> >>
>> > It would be possible to also include the cases in which the
>> > input and output endiannesses are specified (the filter
>> > case), but those lead right back to confusion about the
>> > template argument order.
>>
>> Technically, the output endianness would take the place of the int.
>
> That doesn't fit the pattern because the result is an int, not a "big endian," for example.  Hence the cast is to int first.
>

If you are explicitly converting with a from_type and a to_type, then
(to me) the result is not actually an int, but a to_type.  If you want
to store it into an int, then cast it as one, or use to_type.raw().

>> But then you'd need a secondary cast, I suppose. ie
>>
>> big j = endian_cast<big, little>(k);
>> int i = reinterpret_cast<int>(endian_cast<big, little>(k));
>
> Those aren't casts following the pattern of the new-style casts in the language.
>

Sorry if I wasn't clear, or don't understand - in my mind, k was
typed/stored/declared as an int, it is holding a little-endian value
that needs to be converted to big endian, then stored as another int
(i).

so
int k = some_little_endian_int();
int i =  reinterpret_cast<int>(endian_cast<big, little>(k));
or
int i = endian_cast<big, little>(k).raw();  // interpret k as little,
convert/cast to big, return raw (big) data.

>>
>>    wrapper.data()   //  raw data. or raw_data() or raw() or...
>>    wrapper.value() // converted to host *value*
>
> I could live with raw() and host().  In fact, the copying conversion logic could actually be on that class:
>
>   w.convert<big_endian>();
>   w.convert<little_endian>();
>   w.raw();
>

Yes for the object-based approach.  I like forcing everyone to use
endian_cast<> but I can live with the above as well.

>>    convert_from<big_endian>()
>> is slightly nicer, but
>>    endian_cast<T, big_endian>()
>> isn't really much worse (only 2 characters! (not really...))
>
> Actually, you're comparing those wrong.  convert_from<big_endian>() means convert from big endian to host order.  The equivalent cast requires knowing the host order: endian_cast<T, native_endian>().  I like the former better because it reads nicely, not just that it is shorter.
>

to me

   endian_cast<int>(e)

takes a known endian type and converts to a host int. ie e was
previously declared to be a big_endian or something.  Thus

   endian_cast<int, big_endian>(i)

takes an int (I suppose), reinterprets it as a big_endian, then
converts (swaps if necessary) it to an int.  The 'int' in the cast is
for the return type, not the input type of i.  I wonder if this is the
source of confusion?  If i is not an int, (in particular, if i is an
endian type?) I'm not sure what it should do. And, as mentioned

   endian_cast<little_endian, big_endian>(i)

takes an int, reinterprets it as a big_endian, converts it to a
little_endian, returning a little_endian.

   endian_cast<little_endian, big_endian>(i).raw();

as above, returning an "int".  At least an int by declaration and storage.

>> The benefit of the latter is consistency and explicitness.

Is the above 4 cases clear/consistent/explicit?  It wasn't completely
formed in my mind at the start of this all, so thanks for the
back-and-forth.

>
> Notice how easy it was to get wrong!  It is also not consistent with the normal casts.
>

Yes!  I'm not sure where we diverged, but we have. :-)

Tony