I don't recall you can type fun(intValueField) when fun(double value) is defined. I remember often the compiler wanted me to use the correct data type, that's on C#, but, probably the same for C++. Only arithmatic operations automatically increase its casting to the first term. I recall it failed if I have doule result = inValueField + doubleValueField;. I haven't done all the experiment. All the rules are validated at compile time. And at compile time, 123 can be either int or double decided by compiler, something like that. I don't have confident answers.
C++ is well alive and kicking (in case you missed the last 20 years of computing) and it will continue to do so until a performance oriented - feature rich language will emerge to replace it, such a language does not exist yet, C++ is unique
even thought I used Google Translate, I don't understand the question, name mangling?
He seems to be asking how an invocation of fun(2) can find fun(double) if the name is mangled according to the argument type (double) when the invocation uses a different argument type (int), and whether the compiler simply tries all implicit conversions until it finds a matching name.
If that is the question, then the answer is that that's not how it works. Name mangling is only relevant to the linker, not the compiler. The compiler knows the original name "fun", so can find the function that way, and will then notice it takes a double rather than an int and do the conversion. At that point the compiler will insert the mangled name for fun(double) into the object file so the linker knows which function to link to.
The reason name mangling is relevant at all is because the linker no longer has information about the argument types, so it cannot distinguish between overloaded functions of the same name. Therefore, name mangling is used to make the names of overloaded functions unique. The compiler on the other hand does know the argument types, so it can resolve the function by its original, unmangled name even if the function is overloaded. So the linker uses mangled names, but the compiler does not (other than to emit them to the linker). And since it's the compiler that does overload resolution, the mangled name doesn't come into play there.
@Ion Todirel:In C++, the function exports have decorated names to indicate what kind of parameter it accepts and at what convension. So functions with the same name but different parameters will end with different names. (I assume exports in the case because if it's static linking, the linker should do it's work.)
Therefore he wants to know if the name have changed, how can the compiler find the correct function when implicit conversion is involved.
It seems like the OP got the whole process wrong.
The compiler uses the function prototype declared in header file, it choose the function using the prototype, not the mangled name in the lib file, in fact, the compiler doesn't even know about the lib file, that's the job of the linker.
say you have void fun(double); declared in you header, then you call fun(2), the compiler find the void fun(double) funtion, then it 'generates' the mangled name for it in the obj, then the linker will try to match the mangled name with some other mangled name in the lib file, if it can't find one, then you get a linker error, if happens when your header file doesn't match you lib file.
*snip*C++ is well alive and kicking (in case you missed the last 20 years of computing) and it will continue to do so until a performance oriented - feature rich language will emerge to replace it, such a language does not exist yet, C++ is unique
That was sarcasm (hence the ).
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.