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