Subject: Re: [boost] [Review] Boost.Endian - template requirements and scope
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-07 17:04:06
Le 07/09/11 21:17, Beman Dawes a écrit :
> On Tue, Sep 6, 2011 at 3:39 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Hi,
>>
>> I have not found the requiremenst of the endian class template parapeter T
>> and conversion functions. What are they?
> For class endian, T must be an signed or unsigned integer type. See
> 3.9.1. A UDT that provided the same operations would work, but I'm no
> sure that it is possible to write such a class. Support for promotion
> might be difficult, for example. Since I know of no real-world use
> cases for UDT's, I don't want to waste a lot of time trying to
> determine if they work or not. If we had concepts it would be a
> different story, but that's water over the dam.
I was thinking for example to a integer range class or a value
constrained interger class.
What about enums? Could we use enums as underlying type of boost::endian<>?
> For the conversion functions, the answer is more up-in-the-air. In
> light of comments received, there may be some interface churn with
> these functions.
>
>> Could them be added to the documentation?
> Definitely. Added to do-list.
>
>> I have not found a tutorial on how to use the endian conversions. Could you
>> give an example that shows how easy is to use them with UDT? Collections of
>> UDT?
> They weren't designed with UDT's in mind, but there are likely to be
> only a few requirements, and those requirements could probably be met
> by a UDT.
My question was if you can add an example of a UDT that needs to be
converted from native to the network endian. For example
struct IpHeader {
uint8_t versionHeaderLength; // big
uint8_t differentiated_services; // big
uint16_t total_length; // big
/////////////////////////////
uint16_t identification; //big
uint16_t flags_frag; // big
/////////////////////////////
uint8_t time_to_live; // big
uint8_t protocol; // big
uint16_t header_checksum; // big
/////////////////////////////
uint32_t source_address; // big
/////////////////////////////
uint32_t destination_address; // big
}; // IpHeader
struct UdpHeader {
uint16_t source_port; // big
uint16_t destination_port; // big
uint16_t length; // big
uint16_t checksum; // big
}; // UdpHeader
struct UserMessage {
system_clock::time_point timestamp; // little
uint32_t aircraft_id; // little
struct Position { // little
quantity<si::length, boost::int_least32_t> x; // little
quantity<si::length, boost::int_least32_t> y; // little
quantity<si::length, boost::int_least32_t> z; // little
} position;
struct Attitude {
quantity<si::plane_angle, boost::int_least8_t> heading; // little
quantity<si::plane_angle, boost::int_least8_t> pitch; // little
quantity<si::plane_angle, boost::int_least8_t> roll; // little
} attitude;
}; // UserMessage
struct Packet {
IpHeader ipHeader;
UdpHeader udpHeader;
UserMessage userMessage;
}; // Packet
>> Could the user overload the conversion functions for UDT?
>>
>> While the predefined endian types are useful I guess that the user could
>> instantiate the endian class with a UDT, isn't it? Could you post a working
>> example and add it to the documentation?
> See above. I really want to see real-world use cases before putting in
> any effort.
Showing how we can manage with concrete examples as the preceding one
could show if the interface is good for the every day user work.
>> The scope of Boost.Endian is integer types. Aren't floating point types and
>> endianness related? If the scope of the library is limited to integers,
>> maybe Integer.Endian could be a better name?
> That was the original plan, but I found it easier to not try to
> integrate with the stuff that is already in integer. No big thing one
> way or the other.
>
>
Maybe you can add some words in the documentation that describe more
preciselly the scope.
Best,
Vicente