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 14:20:43

On Tue, Jun 8, 2010 at 1:39 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Dave Handley wrote:
>>
>> The problem is with the initial statement above which says
>> "the endian-types come first, and the straight functions are
>> built on top of that".
>
> Agreed, but note the qualifications that followed.  I took Tony's statement as wishful thinking that might be proven justified, but very likely won't.  Furthermore, I noted that the discussion applied to the copy-based conversion functions.  Since those involve a copy, they could just as easily be built atop the object-based approach as not.  I don't think that dictates a loss of efficiency, but must be proven.
>

Indeed, it is wishful thinking, yet it may be possible.
And indeed I'm wondering if it can be applied to the non-copy case,
where as mentioned, the endian-types are used as the swap 'direction
tags'.  Maybe this is the only worthwhile thing that survives the
discussion.  Too early to tell, but worth exploring, I think.

I suspect the template madness might get too ugly to implement so of
this, hard to tell at this point.

And yes, at the end of the day, actual swap functions need to exist,
and they will probably need to work on raw ints.  Or take endian-types
that are immediately reinterpreted as raw ints.  In fact,
swap_in_place can only take a raw int (or raw_int/indeterminate_endian
:-) as it doesn't make sense for it to be either endian - it is one
endian on the way in, another on the way out!

So the question may just be how much we should expose with a raw-int
interface vs endian-typed, and/or to what degree.  If we could expose
more strongly typed versions *without additional overhead*, I'd prefer
that.  And actually, it is simple to convince yourself that we could.
The problem would be the amount of reinterpret_casts that would be
required by clients.  They would instead resort to
boost::endian::detail... pretty quickly.

So the only question is how to pretty-up the interface, while keeping
it consistent.

Tony

** And actually, I'm starting to think of other uses of
indeterminate_endian...  Maybe it implicitly converts to/from an int
(without any swapping of course) and thus is primarily useful as a
documentation tool. ie

   indeterminate_endian convert_to_big(indeterminate_endian);

is clear about its intent.  The fact that it can take and return ints
without additional casts just makes it useful.