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

Subject: Re: [boost] [endian] endian flip and endian domain
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-06-08 09:47:15

Rob Stewart wrote:
> 
> 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 endianness
>> of a data from/to the native endianness.
> 
> "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.
> 
> 
Well it seems that flip is not too much appreciated :(

Rob Stewart wrote:
> 
> 
>> 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?
> 
> 
It is more a mapping from a type to the endianness of its leaves. For
example if you have two interfaces with different endianess for some of the
leaves of a given type, you will be able to convert the native type to
either interface just supplying the domain.

Rob Stewart wrote:
> 
> 
>> the data to flip can containig 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.
> 
> 
For me swap has the same inconvenient than flip, invert, toggle.

Rob Stewart wrote:
> 
> 
> 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.
> 
> 
I would prefer to separate this as other said the structure of the message
can be provided by a third party. In addition the message structures could
be much more complex than simple POD structs.

Rob Stewart wrote:
> 
> 
>> 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?
> 
> 
to/from are not verbs. I would prefer present_to/from, as what this
functions are doing is part of the presentation layer, for messages for
which the single difference between the physical and the application view is
the endianness of the leaves.

For other messages containing unaligned integers, the presentation will be
more complex. In this case the application structure and the physical
structure are represented by different C/C++ types.

The domain could be used to make this mapping also.

Best,
Vicente
-- 
View this message in context: http://old.nabble.com/-endian--endian-flip-and-endian-domain-tp28811857p28818076.html
Sent from the Boost - Dev mailing list archive at Nabble.com.