Perform 64 bit calculations in 64 bit executable

Question

I am using MinGW64 (with the -m64 flag) with Code::Blocks and am looking to know how to perform 64 bit calculations without having to cast a really big number to int64_t before multiplying it. For example, this does not result in overflow:

int64_t test = int64_t(2123123123) * 17; //Returns 36093093091

Without the cast, the calculation overflows like such:

int64_t test = 2123123123 * 17; //Returns 1733354723

A VirusTotal scan confirms that my executable is x64.

Additional Information: OS is Windows 7 x64.

Answer 1

The default int type is still 32 bit even in 64 bit compilations for compatibility resons.

The "shortest" version I guess would be to add the ll suffix to the number

int64_t test = 2123123123ll * 17;

Another way would be to store the numbers in their own variables of type int64_t (or long long) and multiply the varaibles. usually it's rare anyway in a program to have many "magic-numbers" hard-coded into the codebase.

Answer 2

Some background:

Once upon a time, most computers had 8-bit arithmetic logic units and a 16-bit address bus. We called them 8-bit computers.

One of the first things we learned was that no real-world arithmetic problem can be expressed in 8-bits. It's like trying to reason about space flight with the arithmetic abilities of a chimpanzee. So we learned to write multi-word add, multiply, subtract and divide sequences. Because in most real-world problems, the numerical domain of the problem was bigger than 255.

The we briefly had 16-bit computers (where the same problem applied, 65535 is just not enough to model things) and then quite quickly, 32-bit arithmetic logic built in to chips. Gradually, the address bus caught up (20 bits, 24 bits, 32 bits if designers were feeling extravagant).

Then an interesting thing happened. Most of us didn't need to write multi-word arithmetic sequences any more. It turns out that most(tm) real world integer problems could be expressed in 32 bits (up to 4 billion).

Then we started producing more data at a faster rate than ever before, and we perceived the need to address more memory. The 64-bit computer eventually became the norm.

But still, most real-world integer arithmetic problems could be expressed in 32 bits. 4 billion is a big (enough) number for most things.

So, presumably through statistical analysis, your compiler writers decided that on your platform, the most useful size for an int would be 32 bits. Any smaller would be inefficient for 32-bit arithmetic (which we have needed from day 1) and any larger would waste space/registers/memory/cpu cycles.

Expressing an integer literal in c++ (and c) yields an int - the natural arithmetic size for the environment. In the present day, that is almost always a 32-bit value.

The c++ specification says that multiplying two ints yields an int. If it didn't then multiplying two ints would need to yield a long. But then what would multiplying two longs yield? A long long? Ok, that's possible. Now what if we multiply those? A long long long long?

So that's that.

int64_t x = 1 * 2; will do the following:

1. take the integer (32 bits) of value 1.
2. take the integer (32 bits) of value 2.
3. multiply them together, storing the result in an integer. If the arithmetic overflows, so be it. That's your lookout.
4. cast the resulting integer (whatever that may now be) to int64 (probably on your system a long int.

So in a nutshell, no. There is no shortcut to spelling out the type of at least one of the operands in the code snippet in the question. You can, of course, specify a literal. But there is no guarantee that the a long long (LL literal suffix) on your system is the same as int64_t. If you want an int64_t, and you want the code to be portable, you must spell it out.

For what it's worth:

In a post-c++11 world all the worrying about extra keystrokes and non-DRYness can disappear:

definitely an int64:

auto test = int64_t(2123123123) * 17;

definitely a long long:

auto test = 2'123'123'123LL * 17;

definitely int64, definitely initialised with a (possibly narrowing, but that's ok) long long:

auto test = int64_t(36'093'093'091LL);

Answer 3

Since you're most likely in an LP64 environment, where int is only 32 bits, you have to be careful about literal constants in expressions. The easiest way to do this is to get into the habit of using the proper suffix on literal constants, so you would write the above as:

int64_t test = 2123123123LL * 17LL;

Answer 4

2123123123 is an int (usually 32 bits).

Add an L to make it a long: 2123123123L (usually 32 or 64 bits, even in 64-bit mode).

Add another L to make it a long long: 2123123123LL (64 bits or more starting with C++11).

Note that you only need to add the suffix to constants that exceed the size of an int. Integral conversion will take care of producing the right result*.

(2123123123LL * 17)  // 17 is automatically converted to long long, the result is long long

* But beware: even if individual constants in an expression fit into an int, the whole operation can still overflow like in

(1024 * 1024 * 1024 * 10)

In that case you should make sure the arithmetic is performed at sufficient width (taking operator precedence into account):

(1024LL * 1024 * 1024 * 10)

- will perform all 3 operations in 64 bits, with a 64-bit result.

Answer 5

Edit: Literal constants (A.K.A. magic numbers) are frowned upon, so the best way to do it would be to use symbolic constants (const int64_t value = 5). See What is a magic number, and why is it bad? for more info. It's best that you don't read the rest of this answer, unless you really want to use magic numbers for some strange reason.

Also, you can use intptr_t and uintprt_t from #include <cstdint> to let the compiler choose whether to use int or __int64.

For those who stumble upon this question, `LL` at the end of a number can do the trick, but it isn't recommended, as Richard Hodges told me that `long long` may not be always 64 bit, and can increase in size in the future, although it's not likely. See Richard Hodge's answer and the comments on it for more information.

The reliable way would be to put `using QW = int_64t;` at the top and use `QW(5)` instead of `5LL`.

Personally I think there should be an option to define all literals 64 bit without having to add any suffixes or functions to them, and use `int32_t(5)` when necessary, because some programs are unaffected by this change. Example: only use numbers for normal calculations instead of relying on integer overflow to do it's work. The problem is going from 64 bit to 32 bit, rather than going from 32 to 64, as the first 4 bytes are cut off.