Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at