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 11:25:33

On Tue, Jun 8, 2010 at 11:13 AM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
> On Tue, Jun 8, 2010 at 10:39 AM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
>
> - so am I suggesting a base endian type that can't even be read?   Possibly.
>
>
>   big_endian_int j = from_big_endian_file();
>   int i = endian_cast<int>(j);  // OK
>
>   int k = from_big_endian_file();
>   int i = endian_cast<int>(k);  // FAILS - not sure endian type for k
>
> but then allow specifying the type for k:
>
>   int i = endian_cast<int, big_endian_int>(k);   // OK - k is
> reinterpreted as big_endian_int
>
>
> Does this make sense?  It's still a bit vague in my mind, but I'm just
> wondering if we can somehow manage to use the same functions and
> syntax in both the typed and untyped scenarios.
>
> Tony
>

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.

Which is to say that an int that is in the wrong endian order isn't
really an int, conceptually.  So we should avoid that. Conceptually.
:-)
And I'm thinking that base endian-type should be unreadable on its
own.  This enforces type-safety *and* performance.  From that base
type you can then choose the function-style code or a derived type
that has readability and/or operators.

We should be allowed to swap in place, etc, but the framework should
make it clear that you are doing something like a reinterpret-cast.
To be clear, the function-style doesn't need to start with an
endian-type, but the functions take endian types - which can appear in
the <> brackets, so that you don't have to actually have endian-types.

ie hopefully we can allow you to do whatever you want, but at the same
time get the benefit of type-safety and performance, and a consistent
interface to it all.

ie it is more of a spectrum or more/less typish, than a this or that
divide, to me at least.

Tony