Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Endian - template requirements and scope
From: John Filo (filo_at_[hidden])
Date: 2011-09-09 23:07:21

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? Scoped enums
in C++0x, with their ability to specify the underlying type, seems much
more usable.

> 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.

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. I was worried
that code like the following wouldn't compile at all because the
compiler would think QI, QL, and QB were different incompatible types.
But Boost.Units seems to provide the right magic to make the following
work as desired. Unfortunately, Boost.Endian's lack of implicit
conversion to the endian types limits how well this works (see comment
in main() below)

#include <boost/units/systems/si.hpp>
#include <boost/endian/integers.hpp>

#include <cstdio>

using namespace boost::units;
using namespace boost::endian;

int main()
     typedef quantity<si::length, int> QI;
     typedef quantity<si::length, big32_t> QB;
     typedef quantity<si::length, little32_t> QL;

     QI qi(0x11223344 * si::meters);
     QL ql(0x22334455 * si::meters);
     QB qb(0x33445566 * si::meters);

     printf("%08x (qi)\n", *((int*)(&qi)));
     printf("%08x (ql)\n", *((int*)(&ql)));
     printf("%08x (qb)\n", *((int*)(&qb)));

     qi = ql;
     printf("%08x (qi=ql)\n", *((int*)(&qi)));

     qi = qb;
     printf("%08x (qi=qb)\n", *((int*)(&qi)));

     // These:
     // qb = qi;
     // ql = qi;
     // don't work because the following fail:
     // boost::is_convertible<int, big32_t>::value == true));
     // boost::is_convertible<int, little32_t>::value == true))
     // Likewise for qb=ql and ql=qb;
     // To write to endian types, you have to use the much more clunky:

     ql = QL(qb.value() * si::meters);
     printf("%08x (ql=qb)\n", *((int*)(&qi)));

On a little endian machine, the above should produce:

11223344 (qi)
22334455 (ql)
66554433 (qb)
22334455 (qi=ql)
33445566 (qi=qb)
33445566 (ql=qb)

Note that if the endian types supported something like:

    big32_t x = 0x11223344;

Then all the failed cases would work as well. Beman, if you're reading
this, do you consider the above dangerous and prefer requiring the
explicit conversion (i.e. big32_t x = big32_t(0x11223344)), or is adding
support for implicit conversion something that you wouldn't find

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