Le 10/09/11 05:07, John Filo a écrit :
On 09/07/2011 04:04 PM, Vicente J. Botet Escriba wrote:
What about enums? Could we use enums as underlying type of boost::endian<>?
That would be nice, but it seems of limited use in C++03; Isn't the actual size of an enum unspecified and compiler dependent?
You are right. C++03 enums doesn't allows to specify the underlying type.
Scoped enums in C++0x, with their ability to specify the underlying type, seems much more usable.
Beman, what could be the best way to use C++11 scoped enums and endiannes?
struct UdpHeader { uint16_t source_port; // big uint16_t destination_port; // big uint16_t length; // big uint16_t checksum; // big }; // UdpHeader
I'm curious what you mean when you say UDT. Do you want to be able to say endian<big, UdpHeader>? That seems like a much more difficult problem and way beyond the scope of what Beman's library is trying to do.
No, of course. The parameter should be a model of an integer type with sizeof a sizeof managed by boost::endian. I give already give some cases, for example, what If I recover a specific range/interval class from a 3rd party such as *month* that constraints the values to 1..12 that fix internally the underlying type to int16_t. Could I be able to month as underlying type if month is POD? endian<...., month> If not, does it means that I need to create a template class that behaves as the 3rd party month class but that allows to specify the underlying type? Beman, do you think that such an example could show how the endian class could be used when you have UDT that behaves *like an integer* ?
By the way, it's exactly this type of ubiquitous system struct that makes me think these something like the endian types in Beman's library should become part of the the C++ (and C) standard. It would allow programmers to stop worrying about these issues when dealing with external data.
quantity<si::length, boost::int_least32_t> x; // little
I would do:
quantity<si::length, little32_t>
The above scheme (defining the UDT in terms of the endian types instead of defining an endian type in terms of a UDT) should work in many cases. In fact, it seems like the preferred (or even required) approach in many cases. A small amount of testing seems to indicate that this works fairly well with the current version of Boost.Endian.
This is the correct way to use it when you are working with templates that have as parameter the underlying type. I use it when I want Boost.Bitfield to be endian-safe. I think just that it will be great if examples as the preceding one that show interaction with Boost.Chrono, Boost::Units could be added to a tutorial. Best, Vicente