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:17:04

On Tue, Jun 8, 2010 at 1:05 PM, Dave Handley
<Dave.Handley_at_[hidden]> wrote:
> Gottlob Frege wrote:
>
>> I think what I am saying is that, conceptually at least, the
>
>> endian-types come first, and the straight functions are built on top
>
>> of that (instead of the other way around as most are suggested).
>
>> Now, I wouldn't want that to impact performance, which is why I say
>
>> 'conceptually'.  We can specialize the heck out of everything so that
>
>> performance wins, but I think the conceptual foundation is important.
>
> I disagree.  If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation.  Unless I'm missing something here.  I also don't think this is bad.  Remember that endian swapping happens once at the boundary of the code.  It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho.  Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind.
>

I'm thinking that we can do a typed interface that doesn't enforce a
copy.  Of course, I haven't written the templates yet to prove that.
It may just come down to the 'tags' used in swap_in_place<big_tag,
little_tag>() are also the types we are talking about.

so
   swap_in_place<big_type>(k);

is fine if k is a big_type or little_type (or other endian type).  But
fails to compile if k is an int.

   swap_in_place<big_type, little_type>(k);

would be required for k of type int.  Of course then the order of
types is somewhat confusing.

   cast_in_place<big_type, little_type>(k);

is,... well at least the orde *might* be less unexpected.

Tony