Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-28 16:46:38

> template <typename E1, typename E2, typename T>
> endian<E1, T>& convert_to(endian<E2, T> &e1, endian<E1, T>& e2); // [1]
>
> template <typename E, typename T>
> endian<E, T>& convert_to(endian<E, T> &e1, endian<E, T>& e2); // [2]
>
> convert_to [1] will make the conversion on the e2 parameter and return the 
> address of e2.
> convert_to [2] will do nothing and return the address of e1.
>
> In order to extend this to other types we can define a metafunction that 
> gives the endianess of a type. The result, could be big, little or mixed. 
> The metafunction can be defined for some predefined types and for fusion 
> sequences. So any structure that has defined a fusion adaptor will have 
> the metafunction defined.
>
> The conver_to function of types with the same endianess will behave like 
> [2], so no need for copy neither visiting the structure.
> If the endianess is different then we need to make the conversion if 
> needed and the copy.
>
> This needs some metaprogramming but it seems reasonable, at least to me.
>
> This not solves yet the problem of allocating two different structures and 
> the need to maintain two structures synchronized :(.

In the simple, type-based endian implementation that I attached to a 
previous email in this thread.  You can just write:

int main() {
  struct MyClass { char data[12]; };

  endian<little, MyClass> lil_1;
  endian<little, MyClass> lil_2;
  endian<big, MyClass> big_1;

  lil_1 = lil_2;
  big_1 = lil_1;
  lil_2 = big_1;

} // main

The conversions are automatic and implicit.  The end-user may not even be 
aware of the endianness of lil_1, lil_2, or big_1.
Each assignment requires a copy though.  But I can't think of a use-case 
that wouldn't require at least one copy anyhow.

terry