Re: [Boost-users] [integer] what is the fastest integer type which can hold an 8 bit number?

On 9/10/15 11:59 PM, Neil Groves wrote:

On 11 September 2015 at 05:30, Robert Ramey wrote:

...

Reading the documentation at

http://www.boost.org/doc/libs/1_59_0/libs/integer/doc/html/boost_integer/int...

I invoke the following

using temp_integer = typename boost::int_t<8>::fast;

With the idea of getting the fastest integer type which will hold an 8 bit signed number.

That seems like a very reasonable thing to do! I know you to be very experienced and so I assume there is a reason for not using std::int_fast8_t?

lol - not experienced to know that this even existed. There is a difference though. boost::int_t<N>::fast easily let's me use N as the result of some other compile time calculation. Also std::int_fast8_t is only available in C++11++. But these are not huge issues in the context of the current problem I'm working on. I will likely make my own int_t<8>::fast for this app which invokes the std::int_fastN_t. I know this should be rolled in to the library. Hmmm guess the best is to just open a trac item so that one day it get's fixed.

...

But I get temp_integer equal to a char type. This surprises me. I don't believe that the fastest integer type which can hold an 8 bit signed integer is a char. I looked into the boost/integer.hpp and I can't really figure it out. It doesn't seem to to have any processor specific code in it - which I would think would be necessary to implement the function. What am I missing here?

I don't think you are missing anything. I've taken a look at the Boost.Integer code and the int_fast_t implementation simply provides the LeastInt as the fast type. There is a comment "imps may specialize". I don't know why the Boost.Integer implementation doesn't delegate to the standard library functionality when it is available. It would probably make better defaults and pick up platform optimisations.

probably just needs a little library maintenance.

On modern Intel architectures there's no performance difference taking a temporary in the width of integer types in most scenarios.

This was always my understanding

Hopefully this helps.

It does - thank you. I think Boost.Integer could use some

optimisation to provide an answer more like the standard library by default.

agreed

...

Robert Ramey

Neil Groves