Re: [boost] [boost::endian] Summary of discussion #1

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-06-02 13:26:36

----- Original Message ----- 
From: "Tomas Puverle" <tomas.puverle_at_[hidden]>
To: <boost_at_[hidden]>
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