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

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