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@wanadoo.fr> 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