It is ambiguous: the long argument means the function call doesn't match either of the two overloads.Originally Posted by Nwb
When used as an argument to a function, a short will be promoted to int. Since this then matches the int overload, there is no ambiguity. If you only had a long and a long long overload, on the other hand, it would be ambiguous.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I agree. That's why I mention "type" on quotes. Here I'm considering int as an integral type that is modifiable (short, long, long long - signed, unsigned - auto, volatile - ...). For example, this is also ambiguous:
Code:int f(short int x) { return 1; } int f(unsigned short int x) { return x; } int f(int x) { return 2*x; } int f(unsigned x) { return 3*x; } int f(long x) { return 4*x; } int f(unsigned long x) { return 5*x; } int f(long long x) { return 6*x; } int f(unsigned long long x) { return 7*x; } ... f(2); // which one will be called?
Last edited by flp1969; 02-21-2019 at 04:07 AM.
No, it isn't. The type of the integer literal 2 is int, so the overload with the int parameter will be called.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Ahh, yes... I mean ambiguous in "confusing" sense, not by the standard...
By the way why is double used over float for literals with floating point (unless explicitly mentioned to be double)?
With integer, if the integer literal is longer than int, it would take the type of long long, so why wouldn't floating point use this mechanism?
Because a double would take up more space than a float right, so it would be wasteful. By the way are rvalue literals stored as instructions (i.e part of the program to be loaded for execution of instructions)?
It doesn't seem all that confusing when you aren't leaving out possible overloads though.
I guess that this difference has to do with how integers in a range that can be stored in a short could also be stored in a long with no loss of accuracy, whereas a floating point value in a range that can be stored in both a double and a float, and which is first stored in a float, may end up with less accuracy when converted to double (i.e., when going from less precision to more precision, you cannot make up for precision you didn't have, so you end up less accurate than when the theoretical value is expressed directly in the more precise type), so automatically assigning float or double to the literals without suffix based on the range of the types could end up with unexpected results, hence at some point it was decided that defaulting to double to preserve accuracy would be better.
Where exactly literals are stored in the compiled program is up to the implementation. Anyway, why not?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
But usually where are they stored? What about 'string literals', they're technically lvalues right, so where are they stored?
As laserlight said, it depends on the implementation. And it depends on the level of optimization as well. For exemple, in fragment of code like this, for x86-64:
1. The compiler can store the string in a register:Code:char s[] = "flp"; // local var
2. In the stack:Code:mov edx,0x706c66 ; 'flp\0', little endian
3. Or in the .rodata section:Code:sub rsp,8 ; reserve space for the string (qword aligned) mov dword [rsp],0x706c66 ... add rsp,8 ; take allocated space back.
4. Or the same variation, using the stack... (reservind space, copying the dword, etc).Code:section .rodata s: db 'flp',0 section .text ... initialize local var on a register ... mov edx,[s]
For "primitive" types like char, int, float, double... the compiler prefers to use registers, but, sometimes, stack allocated spaces are used.
In other architectures the rules are different, of course... Well... the compiler knows what to do.
PS: Regarding the compiler preference for registers as storage, some people thinks the 'register' keyword forces the use of registers for a local variables. This isn't the case, necessarily:
Here, the compiler will, probably, allocate both a and b in registers, unless the code tries to get the address-of a. (this way it have no option but to allocate a on stack). The 'register' modifier tells the compiler that it cannot get the address-of b (compilation fails with an error message!).Code:// local vars! int a; register int b;
Registers or cache?
Couldn't edit that reply.
When a variable is declared without the register keyword, could it be stored in the register? I know that static variables could be stored on cache, but cache is not the same as register.
Then register the keyword would be useful. Should somebody like me who's not an expert C++ programmer consider using the keyword?
Registers. Your processor use the Caches to accelerate memory access, but usually this is not under control of your code or the OS.
There is no way, in C, to manipulate the cache directly (except using special functions/instructions [asm]).
When you declare a static local variable it is allocated in data segment, as if it is a global variable (with local visibility). Since your process memory is cacheable, the processor will fetch its memory block to L1 cache, always...
The compiler prefers to allocate local variables in registers, which are faster then using the cache...
Last edited by flp1969; 02-22-2019 at 03:35 AM.
