Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at