2015-09-16 22:09 GMT+03:00 Rene Rivera :

On Wed, Sep 16, 2015 at 2:05 PM, Antony Polukhin wrote:

...

Hi,

It looks like for low-level programming following macro could be really useful:

BOOST_ARCH_BITS_64 BOOST_ARCH_BITS_32 BOOST_ARCH_BITS_16 ?

Predef also missing BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64.

Boost.DLL really needs those macro for detecting bit's dependent elf/macho/pe structures layout. Is it possible to add them?

Maybe.. If I knew what they are supposed to mean? I.e. can you explain what you mean by "bits dependent structures layout"?

BOOST_ARCH_BITS_* is mostly a macro for sizeof(void*). In other words: * define BOOST_ARCH_BITS_64 to 1 on BOOST_ARCH_x86_64, BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64 * define BOOST_ARCH_BITS_32 to 1 on all other archs. -- Best regards, Antony Polukhin

On Wed, Sep 16, 2015 at 11:49 PM, Bjorn Reese wrote:

On 09/16/2015 09:15 PM, Antony Polukhin wrote:

...

BOOST_ARCH_BITS_* is mostly a macro for sizeof(void*).

In other words: * define BOOST_ARCH_BITS_64 to 1 on BOOST_ARCH_x86_64, BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64 * define BOOST_ARCH_BITS_32 to 1 on all other archs.

That would be incorrect because there are other 64-bit architectures besides those listed above. For gcc and alikes you can use the __SIZEOF_POINTER__ predefined macro, this would conveniently cover most of the architectures.

That appears to be of limited use. I would much rather see this extended to macros for data models (e.g. LP32, LP64, ILP64, etc.)

http://www.unix.org/whitepapers/64bit.html

I think adding integer sizes to the macro semantics is going to be unhelpful. Pointer size is often taken as an indicator of the target addressing mode and integer sizes are irrelevant for that. In fact, when you care about integer sizes you'll just use intXX_t types regardless of the sizes of the builtin integer types. I also think that the proposed naming is confusing. I would suggest BOOST_ARCH_ADDRESS_MODEL (to follow the Boost.Build option) or BOOST_ARCH_POINTER_SIZE.