Wanna be sure what var declared as int is _int64.
May be some define symbol for it?
Printable View
Wanna be sure what var declared as int is _int64.
May be some define symbol for it?
#define int _int64
assert(sizeof(int) == 8, "int the wrong size")
Why are you not going to use _int64?
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:
Code:namespace MyCompanyName
{
typedef _int64 Int64;
}
That's absolutely illegal. You are not permitted to define macros with names identical to language keywords.Quote:
Originally Posted by ninja9578
assert takes one argument; I think you meant assert((expression) && "string-literal"), instead.Quote:
Originally Posted by ninja9578
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.
Use a static assert, so that any attempt to use ints that are not 64 bit won't compile:Quote:
Originally Posted by ninja9578
This simple line will compile OK if ints are 8 bytes, and will fail if they are not.Code:char dummy[sizeof(int) == 8];
Regards,
Paul McKenzie
Why? This program compiles and runs:Quote:
Originally Posted by Plasmator
Replacing short by int diesn't compile, because preprocessor converts function header to:Code:#define short std::cout
int _tmain(int argc, _TCHAR* argv[])
{
short << "OK" << std::endl;
return 0;
}
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.
It doesn't matter what your compiler is willing to swallow -- this sort of thing is explicitly forbidden by the standard.Quote:
Originally Posted by Alex F
If you're writing portable and well-defined code, you mustn't do this.
I had the impression that the rule was broadly applicable, but it appears to be applicable only when a standard header is included:Quote:
Originally Posted by Alex F
Quote:
Originally Posted by C++03 Section 17.4.3.1.1 Paragraph 2
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.Quote:
Originally Posted by Alex F
Of course, I may have missed out a more broadly applicable rule, and perhaps this qualifies:
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.Quote:
Originally Posted by C++03 Section 2.10 Paragraph 2
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?Quote:
in which case the rule I cited comes into effect and the program has undefined behaviour.
Consider the following, for example - accepted by Comeau and MSVC9 without complaint
Code:#include <iostream>
#include <cstdlib>
#undef NULL // illegal
#define void std::cout // illegal
#define malloc std::endl // illegal
int main()
{
void << "test" << malloc;
return 0;
}
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.Quote:
Originally Posted by Plasmator
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.Quote:
Originally Posted by Speedo
Quote:
Originally Posted by Speedo
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.Quote:
Originally Posted by Alex F