Subject: Re: [boost] [boost::endian] Request for comments/interest
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-28 18:21:02
----- Original Message -----
From: "Terry Golubiewski" <tjgolubi_at_[hidden]>
To: <boost_at_[hidden]>
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