can i force compiler to use 64 bit int?

[Igor Yalovecky]

Wanna be sure what var declared as int is _int64.

May be some define symbol for it?

[ninja9578]

#define int _int64
assert(sizeof(int) == 8, "int the wrong size")

Why are you not going to use _int64?

[Zaccheus]

If all int are treated as _int64 then will that not cause problems with the headers of libraries which you link to ?

If you just want int to be 64 bit in your own code, and always want it to be 64 bit, then I would typedef my own int type:

namespace MyCompanyName
{
typedef _int64 Int64;
}

[Plasmator]

#define int _int64

That's absolutely illegal. You are not permitted to define macros with names identical to language keywords.

assert(sizeof(int) == 8, "int the wrong size")

assert takes one argument; I think you meant assert((expression) && "string-literal"), instead.
In either case, a run-time assertion is less than optimal. This sort of thing should be enforced at compile-time. A simple static assertion will handle this more gracefully.

[Paul McKenzie]

#define int _int64
assert(sizeof(int) == 8, "int the wrong size")

Use a static assert, so that any attempt to use ints that are not 64 bit won't compile:

char dummy[sizeof(int) == 8];

This simple line will compile OK if ints are 8 bytes, and will fail if they are not.

Regards,

Paul McKenzie

[Alex F]

That's absolutely illegal. You are not permitted to define macros with names identical to language keywords.

Why? This program compiles and runs:

#define short std::cout

int _tmain(int argc, _TCHAR* argv[])
{
    short << "OK" << std::endl;
    return 0;
}

Replacing short by int diesn't compile, because preprocessor converts function header to:
std::cout _tmain(std::cout argc, _TCHAR* argv[])

We can define any macro, but result may be very interesting... Of course, making int macro destroys the program completely. Agree with Zaccheus, typedef is the best solution.

[Plasmator]

Why? This program compiles and runs:

It doesn't matter what your compiler is willing to swallow -- this sort of thing is explicitly forbidden by the standard.

If you're writing portable and well-defined code, you mustn't do this.

[laserlight]

Why?

I had the impression that the rule was broadly applicable, but it appears to be applicable only when a standard header is included:

A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords.

This program compiles and runs:

It is not standard C++. To make it standard C++, we would likely #include <iostream> (besides changing _tmain(int argc, _TCHAR* argv[]) to main(int argc, char* argv[])), in which case the rule I cited comes into effect and the program has undefined behaviour.

Of course, I may have missed out a more broadly applicable rule, and perhaps this qualifies:

In addition, some identifiers are reserved for use by C++ implementations and standard libraries and shall not be used otherwise; no diagnostic is required.

though it then seems strange to forbid defining macros for names lexically identical to keywords in a more specific case if this rule already covers the general case.

[Speedo]

in which case the rule I cited comes into effect and the program has undefined behaviour.

Is that really the case though? While this specific scenario may not technically be defined, the rules for how the preprocessor handles macro substitution are clearly defined, so unless a particular vendor explicitly blocks macros from having the same names as keywords, the preprocessor will do what it always does. It also doesn't help that the other rules in that section are essentially unenforceable. How exactly are you going to prevent someone from defining a macro with the a name declared in a header?

Consider the following, for example - accepted by Comeau and MSVC9 without complaint

#include <iostream>
#include <cstdlib>

#undef NULL // illegal
#define void std::cout // illegal
#define malloc std::endl // illegal

int main()
{
  void << "test" << malloc;
  return 0;
}

[Alex F]

It doesn't matter what your compiler is willing to swallow -- this sort of thing is explicitly forbidden by the standard.

If you're writing portable and well-defined code, you mustn't do this.

Of course I don't do this, but the point is what code is working, and what code doesn't work. Macros are handled by preprocessor, and it didn't read your post.

[laserlight]

Is that really the case though? While this specific scenario may not technically be defined, the rules for how the preprocessor handles macro substitution are clearly defined, so unless a particular vendor explicitly blocks macros from having the same names as keywords, the preprocessor will do what it always does. It also doesn't help that the other rules in that section are essentially unenforceable. How exactly are you going to prevent someone from defining a macro with the a name declared in a header?

Indeed. I wonder if this is a case of where the standard committee wanted to give more leeway to compiler vendors, even if the leeway is not actually used by modern compilers. But it does not square with the rule only being in effect when a standard header is included, since that would only concern standard library implementers, who are not necessarily the compiler vendors.

Consider the following, for example - accepted by Comeau and MSVC9 without complaint

Of course I don't do this, but the point is what code is working, and what code doesn't work. Macros are handled by preprocessor, and it didn't read your post.

Using an apparently working program to prove that the code works fails in the presence of undefined behaviour, unless you exhaustively test all current and future compilers (or simply restrict your statement to say that it works for certain compilers, with the given versions and configurations). Plasmator's post does not matter, but the C++ Standard matters.