typedef boost::int_t::fast fastint_t;

Nice, but why isn't this part of the standard distribution as a "word_t" or something? Just curious why it's not there already. Rodrigo

On Thu, Oct 30, 2008 at 8:41 AM, Cory Nelson wrote:

On Thu, Oct 30, 2008 at 8:24 AM, Daryle Walker wrote:

...

Is there a macro and/or typedef that will tell me bit-length used for a processor and/or the best integer type for said processor? The "int" type is supposed to be that type, and it was in the 16- and 32-bit eras. (I learned C programming with the former in the... early 1990s!) However, the powers-that-be decided, for "backwards compatibility," to freeze "int" and "long" at 32 bits and use a new type, "long long," for 64 bits, which should be the optimized integer type for 64-bit processors. (If they kept to the plan, "int" would be 64 bits, "long" either 64 or 128, "short" up to 32, and the new type will be "short short" at 16.) I want to know the best type so, when I build multi-integer arrays for various purposes, I don't pick an element type that causes a slow down, whether to focus on a fraction of a register (if the chosen type is too small) to handle two registers at once (if the chosen type is too large).

Most things don't need 64-bit ints, so it would just be wasting memory to use them if 32-bit ints are as fast or faster. This is why "int" stays 32-bit on most x64 ABIs.

IMO, on a 64-bit CPU int should be 64 bits, and long should be 128 bits, except if adding two 64-bit values that are already in registers is slower than if they were 32-bit. I don't buy the argument that this wastes memory. When a given integer type uses too much memory for your needs, you can store a smaller type in your structs; you can even use bitfields if you need a portable way to tinker with an integer's memory footprint. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Thu, Oct 30, 2008 at 12:15 PM, Rodrigo Madera wrote:

...

IMO, on a 64-bit CPU int should be 64 bits, and long should be 128

I agree that such a type should be available. Maybe not all ints directly, but have a word_t for that purpose.

People may argue that "it's not needed" or redundant or whatever, but having the register width as a type could be really useful sometimes.

As the original message said, int is supposed to be the type that matches the CPU register size. The semantics of the C/C++ expressions have been carefully designed for that purpose of int. For example, adding 2 shorts in C/C++ produces an int (not a short), because a typical CPU works most efficiently with full registers (in fact it may not even have "half registers".) With int being 32-bit on a 64-bit CPU, a C compiler is forced to generate code that works with half registers, which would have been inefficient had most 64-bit CPUs not been designed with this in mind. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Thu, Oct 30, 2008 at 13:08, Othman, Ossama wrote:

...

If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:

typedef boost::int_t::fast fastint_t;

Why not just use the standard {u}intptr_t or {u}intmax_t typedef in this case?

For intptr_t, this message comes to mind: http://lists.boost.org/Archives/boost/2005/09/94158.php And intmax_t is the wrong choice on 32-bit systems that provide a 64-bit type.

Scott McMurray wrote:

On Thu, Oct 30, 2008 at 13:08, Othman, Ossama wrote:

...

...

If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:

typedef boost::int_t::fast fastint_t; Why not just use the standard {u}intptr_t or {u}intmax_t typedef in this case?

For intptr_t, this message comes to mind: http://lists.boost.org/Archives/boost/2005/09/94158.php

True, but IMO it is an error in the C standard, that it did not add a similar statement for (u)intptr_t as it does for the exact integer types (u)intN_t, which says in 7.18.1.1/3: "These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names." If this had been done, you could always use (u)intptr_t where boost::int_t::fast would be a feasible instantiation. Side note: Is anyone aware of the proper forum/contact person to address this issue to persons near to the C standard? Just my 2 euro cents, Daniel