...

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, ""); 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. I prefer to test with compile-time assert on the number of binary digitsin the type, as given in <limits>. For example: #include <cstdint> #include <limits> #include <type_traits> #include <boost/cstdint.hpp> static_assert(std::numeric_limits<boost::unit32_t>::digits == 32, "Error: wrong digit count for boost::uint32_t."); static_assert(std::numeric_limits<std::unit32_t>::digits == 32, "Error: wrong digit count for std::uint32_t.");

This is because either of boost::uint32_t or std::uint32_t on ARMmight use a type like unsigned long, or unsigned int under-the-hood,and these may disagree for a different compiler. It gets even worse when porting to an 8-bit platform whereint might have 8 bits or 16 bits and a 32 bit integer typemight need long or long long. Cheers, Chris On Monday, November 23, 2015 11:51 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote: 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost