[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [Config] boost::uint32_t != std::uint32_t on some	targets
From:       Christopher Kormanyos <e_float () yahoo ! com>
Date:       2015-11-23 19:31:07
Message-ID: 1676027353.8839271.1448307067166.JavaMail.yahoo () mail ! yahoo ! com
[Download RAW message or body]

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


  

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


[prev in list] [next in list] [prev in thread] [next in thread]