----- Original Message ----- From: "Tomas Puverle" <tomas.puverle@morganstanley.com> To: <boost@lists.boost.org> Sent: Wednesday, June 02, 2010 5:37 PM Subject: [boost] [boost::endian] Summary of discussion #1
Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit.
Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions.
This could be the best option. What about creating a ticket?
Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>().
I don't think having several names for the same purpose is a good idea. We need to choose between swap and /to/from. Given that both will be used on the endian namespace we have endian::swap<endian::host_to_{little/big}>() endian::from<{endian::little/big}>() endian::swap<endian::host_to_{little/big}>() endian::swap<endian::{little/big}>() While I find the name swap_in_place apropiated, I dont find swap is correct (maybe due to my poor English), as there is no swap at all . In addition we have already swap that takes always two arguments. What about to "convert_to" "convert_from" endian::convert_from<{endian::little/big}>() endian::convert_to<{endian::little/big}>()
The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol.
I agree. I don't see any added value to name big as network. In the same way the library defines a typedef for native, the user can define its own typedef for network.
Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used.
Does it means that swap_in_place on a structure containing a floating point will be undefined, or that the library will fail to compile or throw an exception in this case?
Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values.
Do you plan to define the typed version independently of Boost.Endian? I'm not yet sure we can have a typed version for swap_in_place that has no execution cost when the endianess are equal. But I find much more clear the typed version than the swap interface when copy is used. int j; int i = endian::swap<endian::host_to_big>(j); --- versus --- int j; endian<big,int> i = j; or int j; int i = endian::swap<endian::big_to_host>(j); --- versus --- endian<big,int> j; int i = j; There is also another feature the endian class provides and is the ability to work with integers with an arbitrary number of bytes. For example we can have a physical structure such as struct X { endian<big, int, 24> i; endian<big, int, 16> j; endian<big, int, 24> j; };
Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future.
There is already a GSoC project (Brian Bartman) that is working on an extension of Boost.Bitfield. The idea is to a have a kind of fusion sequence adaptor on top of Boost.Bitfield. Used to easily manipulate groups of bitfields the same way as does C bitfields, but in a portable manner. Example declaration: struct Rgb565 { struct red {}; struct green {}; struct blue {}; typedef bitfields< endianess<big> bitfield<unsigned char, red, 5>, bitfield<unsigned char, green, 6>, bitfield<unsigned char, blue, 5> > type; }; Example usage: Rgb565::type r = make_bitfields<Rgb565::type, 1,2,3>; // Write to a bitfield. r.get<Rgb565::red>() = 23; //or r.set<Rgb565::red>(23); // Read from a bitfield Rgb565::at<Rgb565::blue>::value_type b = r.get<Rgb565::blue>(); Other posibility could be to use unamed bitfields whic are accessed as tuples. typedef bitfields<big, 5,6,5> Rgb565; Rgb565 r; r.get<0>() = 23; // or r.set<0>(23); // Read from a bitfield Rgb565::at<2>::value_type b = r.get<2>(); If you have other ideas for a Bitfield library, we are open to any suggestion. Best, Vicente