Boost logo

Boost :

Subject: Re: [boost] [Config] boost::uint32_t != std::uint32_t on some targets
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-11-23 05:51:00

On 2015-11-22 20:24, Louis Dionne wrote:
> Dear Boost,
> I recently fell into a trap where a program wouldn't compile because of a
> difference between `boost::uint32_t` and `std::uint32_t`. Specifically, I
> was trying to cross-compile from OS X to ARM, and the following program
> wouldn't compile
> #include <boost/cstdint.hpp>
> #include <cstdint>
> #include <type_traits>
> static_assert(std::is_same<std::uint32_t, boost::uint32_t>::value, "");
> int main() { }
> I was building with
> arm-none-eabi-g++ -I /path/to/boost -std=c++11 -c main.cpp
> I have asked a question on StackOverflow [1], and I now understand why the
> two types are not required to be the same. However, I think it is a QOI
> issue that those two types are not the same, since it makes interoperating
> between `std::uint32_t` and `boost::uin32_t` more difficult. Is there a
> reason for this difference, and if not would it be reasonable to ensure that
> `boost::uint32_t == std::uint32_t` whenever the latter is defined, i.e. in
> C++11 and above?

boost/cstdint.hpp is based on stdint.h or inttypes.h when possible -
presumably, as well as cstdint. So I'd say the intention is for the
integer typedefs to be the same.

My guess is that the problems is caused by BOOST_HAS_STDINT_H not
defined on your platform. If you have a usable stdint.h then this macro
should be defined and the problem should go away. Otherwise the platform
should be detected directly in boost/cstdint.hpp. In any case it would
be easier if you could prepare a PR.

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