Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data

Subject: Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-11 07:13:09

vicente.botet wrote:
>
> I have a implemented a prototype that allows to make endian
> conversions in place respect to an endian point of view
> (domain) of endian unaware data. The point of view is
> represented by a map from the native data types to an endian
> tree, which have mpl sequences as nodes and the leaves are
> the endianess of the integer types.

I have no idea what that means.  (Having now examined the example you provided below, I have a better idea, but as expressed it doesn't tell me much.)

> Two functions to convert any data in place are provided:
>
> template <typename Domain, typename T>
> void convert_from(T& r);
>
> template <typename Domain, typename T>
> void convert_to(T& r);
>
> The default implementation works for fusion sequences. So the
> user will need to adapt the structures so them are viewed as
> fusion sequences or overload the functions.

OK.  That much seems reasonable.

> Next follows an example that defines 3 structures, and a
> point of view (domain) that see one of then as big, the
> second as little and the third as a mix of big and little.
>
> using namespace boost;
> // native structs definition
> namespace X {
> struct big_c {
>     uint32_t a;
>     uint16_t b;
> };
> struct little_c {
>     int32_t a;
>     int16_t b;
> };
> struct mixed_c {
>     big_c a;
>     little_c b;
> };
> }
>
> // definition of a point of view (domain)
> struct network {};
>
> // mapping of native types to an endian tree  for the network
> point of view (domain)
> namespace boost { namespace endian {
>     template <>
>     struct domain_map <network, X::big_c> {
>         typedef mpl::vector<big,big> type;
>     };
>     template <>
>     struct domain_map <network, X::little_c> {
>         typedef mpl::vector<little,little> type;
>     };
>
> }}

I have no idea what that means.  (Having now studied the rest of the example, I understand the purpose for the above, but that doesn't mean I really understand it.)

> // view of the structures as fusion sequences
> BOOST_FUSION_ADAPT_STRUCT(X::big_c,
>     (uint32_t, a)
>     (uint16_t, b)
> )
> BOOST_FUSION_ADAPT_STRUCT(X::little_c,
>     (int32_t, a)
>     (int16_t, b)
> )
> BOOST_FUSION_ADAPT_STRUCT(X::mixed_c,
>     (X::big_c, a)
>     (X::little_c, b)
> )

The type duplication is unfortunate, but that was necessary in Beman's approach, too.

> int main( int argc, char * argv[] ) {
>
>     X::mixed_c m;
>     // fill with data from the 'network' domain (emulating
> the reception from the domain 'network')
>     m.a.a=0x01020304;
>     m.a.b=0x0A0B;
>     m.b.a=0x04030201;
>     m.b.b=0x0B0A;

This is just putting raw data, of assumed endianness, into the structures, right?

>     // convert from the network to the native domain
>     endian::convert_from<network>(m);

Here you have declared that the current data in m is in network order and requested that it be converted to host order, right?

That's no different, other than implementation details, than what Tomas originally provided, IIUC.

>     // convert from the native to the network domain
>     endian::convert_from<network>(m);
                      ^^^^
to?

> The library could define three predefined maps for the domain
> endian::native, endian::big, endian::little, which maps every
> leaf to the corresponding endian type.

That's an appropriate step, given the commonality of those options.

> I have not see the assembler generated, but the design is
> there to do nothing when the in place conversion concerns the
> same endianness.

That's a necessity.

> The library is based on the one from Beman's.
> * I have split the the endian class on two levels:
>   - endian_pack
>   - endian.
> * replaced the enum class endianness by a endianness tag (see above)

Tomas already noted that he didn't like the use of enums, so you're on the same page there.

> * I have added an endian_view class that is a reference to a
> native type viewed with a specific endianess (a kind of endian_cast).

That's not unlike Beman's approach in that every access does the conversion, right?  Doing that with a view is nice.

> * An last I have added on top the requested 'in place
> conversion' functions.
>
> The last two features work with endian anaware data. I could
> add pure conversions if needed on endian anaware data.

I presume by "anaware" you mean "unaware."

What do you mean by "pure conversions?"  Do you mean the lower level, function-based interface?

If I understand your proposal, you're trying to avoid the need to define a duplicate structure, just to express the source endianness, by instead applying a convert_to/from with a mapping describing the endianness of each field (or all fields?) of the data and the desired order, to convert the data.  Is that right?  Obviously, the scaffolding required by your approach must be compared against the parallel definition to see which is clearer, more functional, and performs better.

I'd like to see Tomas provide the same behavior using his approach and then we can compare them directly.  We'll also want to examine the performance differences, if any.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.