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
int k = some_little_endian_int();
int i = reinterpret_cast<int>(endian_cast<big, little>(k));
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:
Yes for the object-based approach. I like forcing everyone to use
endian_cast<> but I can live with the above as well.
>> 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.
takes a known endian type and converts to a host int. ie e was
previously declared to be a big_endian or something. Thus
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
takes an int, reinterprets it as a big_endian, converts it to a
little_endian, returning a little_endian.
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
> 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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk