----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> To: <boost@lists.boost.org> Sent: Friday, May 28, 2010 10:46 PM Subject: Re: [boost] [boost::endian] Request for comments/interest
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.
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
Maybe, but what about more heterogeneus structures?
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.
I was trying to prove that, the endian "type safe" approach can avoid as well copies (respect to the "untyped" approach) when not necesary, while continue to been type safe. Vicente