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-10 00:45:27

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


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