Re: [boost] [endian] endian flip and endian domain

Subject: Re: [boost] [endian] endian flip and endian domain
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-08 07:05:36

vicente.botet wrote:
>
> I think that I have found a good name that can be used
> instead of the swap_in_place: "flip". This recall the flip
> operation used in bitset exchanging the value of a bit. On
> the endian context this will exchange in place the endianess
> of a data from/to the native endianess.

"Flip" is not appropriate to my mind.  It works well for bits because they are binary, but it doesn't convey the idea of reordering bits/bytes to a specific sequence.  I prefer my suggestion of "reorder" because, after all, the operation (ostensibly) reorders the data.

> As the same data can be used with different endianess
> depending of the the context,  the flip function  needs a
> specific parameter, let me call this the endian domain. As

Your "domain" idea is nothing other than "endianness" as far as I can tell.  Why invent a new term?

> the data to flip can containg part that are big and others
> that are little endian, we need to map all the leaveds of the
> tree associated to the data structure. The domain mill map
> staticaly the data to its endianess. For fundamental types
> this will be reduced to a single endian value, but for
> structures, the map will be a tree having as leaves endian types.

When applied to a UDT, "flip" seems even worse as it suggests that things that are currently big endian will be "flipped" to little and vice versa, whereas "reorder" and "swap" can be interpreted easily as making everything uniform.

The rest of what you're suggesting, as near as I can tell, is to create a compile-time data structure constructed from an existing structure by using Fusion.  Presumably, you would be able to declare each field's endianness independently.  Using the compiler, via macros and template meta-programming, to create the parallel UDT for a given UDT (such as an OS-provided structure) is highly valuable as it removes most of the hassle of and propensity for error from duplication in such cases.

> This mapping allows us to separate the endian concern from
> the data itself in a clear way. For structures that have been
> adapted as fusion sequences, we can define flip_to/from
> functions that will do the the flip in a generic way. Of
> course the user could always overload the flips functions to
> provide its own implementation.

How is flip_to/flip_from clearer than the previous suggestions of to/from?

_____
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.