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-tp28811857p2881... Sent from the Boost - Dev mailing list archive at Nabble.com.