I have been reading about "Name resolution" in wikipedia (Name resolution WIKI) and it has been given in that that C++ uses "Static Name Resolution". If that is true then I couldn't figure out how C++ manages to provide "polymorphism" without using dynamic name resolution.
Can anyone please answer whether C++ uses "Static Name Resolution" or "Dynamic Name Resolution". If it is static, can you also explain how C++ provides polymorphism.
Wikipedia's definition of name resolution is about how tokens are resolved into the names of constructs (functions, typenames, etc). Given that definition, C++ is 100% static with its name resolution. Every token that represents an identifier must be associated at compile-time with a specific entity.
C++ polymorphism is effectively cheating. The compiler can see that a static name resolves to a member function defined with the virtual keyword. If the compiler sees that the object you are calling this on is a dynamic object (ie: a pointer/reference to that type rather than a value of that type), the the compiler emits special code to call that function.
This special code does not change the name it resolves to. What it changes is the function that eventually gets called. That is not dynamic naming; that is dynamic function dispatch. The name gets resolved at compile-time; the function gets resolved at runtime.
C++ use static name resolution because it renames each function to made each one have an unique.
That mean that the function int foo(int bar) will be known by the compiler as something like _Z3fooi, while int foo(float bar) will be known as something like _Z3foof.
This is what we call name mangling.
Related
In C++, is there a difference between name binding and name lookup in? The working draft C++14 standard (N4296) defines name lookup in (3.4) as
Name lookup associates the use of a name with a declaration (3.1) of that name.
I can't find a definition for name binding in the standard, but the IBM Knowledge Center documentation for their XL C/C++ compiler defines:
Name binding is the process of finding the declaration for each name that is explicitly or implicitly used in a template.
The only distinctions between the two definitions seem to be that (1) name binding refers specifically to a name used in a template and (2) name binding refers to a name, while name lookup refers to the use of a name.
However, Section (13.3) on Overload Resolution in the C++ standard mentions binding frequently, but without defining it. The way 'binding' is used in this context makes it seem that binding refers to the association of an argument with a function parameter.
At first, this definition seems different from either of the other two definitions, thought it fits (broadly) the definition of name lookup if we assume that the name of the function is being bound to its declaration by comparing the types of arguments and parameters. That isn't exactly the sense used in Section (13.3), but I'm trying to make sense of the standard without a proper definition.
In short, if anyone has a good definition of 'name binding' or 'binding', I'd be grateful.
Having read the relevant parts of Wilson & Clark Comparative Programming Languages, I think I have a better understanding of the topic. If I surmise correctly, the term 'binding' covers a gamut of related terms, including name-declaration binding, name–type binding, declaration-reference binding, reference-value binding, and name-value binding.
"Name lookup" seems to be a synonym for name-declaration binding. The other uses of 'binding' in the C++14 standard relate to various combinations of the other varieties of binding.
Please correct me if I'm wrong!
What is the difference between definition and instantiation?
Sub-question: Are "variable definition" and "variable instantiation" the same?
int x;
The above code can be reffered to as both a variable definition as well as a variable instantiation, right? If so, my question is if these two terms are synonyms? (or is there a different relation between them?)
After quite some edits and also a correction made by Johannes Schaub:
A definition of a variable of a certain type creates a variable of that type. As far as Stroustrup is concerned, this also holds for the definition of objects of a certain class, since a class is nothing more than a (non-native) type. (This makes much sense, although it isn't general OO terminology.)
General object oriented termininology: Instantiation of a class creates an object of that class. Specialized C++ terminology: Instantiation of a template creates a "perfectly ordinary" (Stroustrup) class.
A class is a type, defined in code, rather than as part of the language.
An implementation is a concrete class that realizes the functionality specified in an abstract class from which it derives.
A declaration is a specification of a variable or function, without allocating memory for it or generating code for it.
So #Riko, the definition on learncpp.com specifying that a definition implements an indentifier is not very accurate. Interfaces can be implemented, not types or classes. But one part of the definition is valuable: Definition in general goes hand in hand with memory allocation. You can declare a function or variable as often as you want (e.g. a declaration in a header file), but you an define it only once. If you declare a function, you give the signature (the name, return type and params, but not the body).
If you declare a variable, you used to put the word extern in front of it in a header file, but that isn't done often anymore, since object orientation and classes took over. Defining a variable in a header file, on the other hand, may lead to multiple instances of the variable, since the same header is read during compilation of distinct source files. Since C++ uses independent compilation and just textually includes the header, the variable is defined in multiple files, so there are several variables under the same name. Linkers don't like such ambiguity and will complain.
While the term instantiation in general means "creating an object of a class", Stroustrup (maker of C++) uses it in a special sense: A class is an instance of a template with all its parameters resolved. Nevertheless in many texts on C++ the word instantiation is used in the general Object Oriented sense, which is confusing.
#Jonannes Schaub. Although I am not too happy with C++ terminology deviating from general OO terminology, I think it's right to follow Stroustrup here, since after all, he created the language.
There are:
1) variable definitions,
2) variable/object instantiations, and
3) template instantiations.
1 & 3 are specific C++ terminology. 2 is more general terminology that might be used with C++. It is not an "officially" defined term for C++.
I understand that your question is about 1 and 2, but not 3. 3 is different than 2, though related in meaning. I won't address 3 further as I don't believe it is part of your question.
Instantiation is the creation of an object instance. It is more usual to use the term in reference to a class object than something like an int or double.
A C++ variable definition does cause an object of the type being defined to be instantiated. It is, however, possible in C++ to instantiate an object other than via a variable definition.
Example 1:
std::string name;
The variable name, a std::string, is defined and (at run-time) instantiated.
Example 2:
std::string *namePointer;
The variable namePointer, a pointer, is defined and might be said (at run-time) to be instantiated (though not initialized). There is no std::string variable and no std::string is instantiated.
//simple example, not what one should usually write in real code
namePointer = new std::string("Some Text");
No additional variable is defined. A std::string object is instantiated (at run-time) and the separate and pre-existing namePointer variable also has its value set.
Definition and Declaration are compile time concerns.
Declaration and definition of identifiers happens while your program is being compiled.
Declaration: A declaration is telling the compiler about the type of an identifier that is defined somewhere else but may be referenced here.
Definition: There can be only one definition of an identifier. This is where the thing is actually defined. All the declarations refer to this definition.
Mostly this is only a distinction we make with classes because built in types are already defined (the compiler already knows what an int is). The only exception I can think of is when we declare a variable to be extern.
Instantiation, this happens at run time.
An object is an instance of a class.
Instantiation is the act of creating a new object.
Instantiation of an object happens while your program is being run. Instantiation is when a new instance of the class is created (an object).
In C++ when an class is instantiated memory is allocated for the object and the classes constructor is run. In C++ we can instantiate objects in two ways, on the stack as a variable declaration, or on the heap with the new keyword. So for the class A both of the following create an instance of the class (instantiate it)
struct A {
int a;
};
A inst1;
A* inst2 = new A();
inst1 is a local variable that refers to an instance of the class A that was just created on the stack.
inst2 is a local variable that holds a pointer to an instance of class A that was just created on the heap.
There may be some confusion because the first is not possible in Java or C#, only the second. In C++ both instantiate (create a new runtime instance of) the class A. The only difference beteween the two is scope and where the memory was allocated.
Suppose I've written a foo<T> function (I have a full signature with namespaces), but never mind that right now); and suppose there is no other function overloading it (in the relevant namespace it's in). Now let's place ourselves at runtime. Suppose I have the string "foo", and for some type MyType, I have typeid(MyType) (from the <memory> header).
Can I somehow obtain the symbol name for foo<MyType>?
Second version of this question: Now suppose I have the full signature of foo as a string, instead of just the name; and drop the assumption about no overloads.
Notes:
No, I'm not asking about the symbol itself, just the name. That would be an interesting question for another time.
Answers which depend on foo<T> coming from a shared library are relevant, although I don't think it should matter just for the symbol name.
I don't care about performance here, I'll do whatever it takes. Help me Obi Wan, you're my last hope etc. So, RTTI, compiling with weird flags, whatever.
Platform-dependent answers are also relevant: GNU/Linux with kernel version >= 3.x , an x86_64 CPU , gcc >= 4.8 .
No, you can't.
To get the mangled name of an instantiated function template, you need in the simplest case the following information:
The fully qualified name of the function (you said you only have "foo", what if the function is in a namespace?)
The types of all template type arguments (the mangled name of the type may suffice, if the mangling scheme for the function name embeds the type name directly; otherwise you'd need the full type name, potentially recursively into all template arguments of the type).
The types of all function arguments (same caveat applies).
This is assuming that you don't have template template parameters, or non-type parameters. It gets a lot more complicated when you have those, since it may require mangled forms of entire expression trees. It also assumes that you're not dealing with partial or full explicit specialization, which is even more complicated. And it is finally assuming that your function doesn't have any special decoration due to compiler-specific extensions (e.g. __stdcall in 32-bit Windows environments). Oh, and some ABIs may encode the return type of the function as well.
Since according to your premise you only have the function name (not clear on whether it is fully qualified) and the type_id objects of the template arguments (which may work as a source of the mangled type name, but do not on all platforms), you have insufficient information to recreate the mangled name.
This leaves the option of obtaining a list of all compiled symbols from your binary (if such is available) and searching for a most likely candidate, which is of course error-prone.
We all know that all the functions in C++ are name mangled during the compile time only, so is this applied to virtual functions too?
Yes. Member function names are mangled. They need to embed their argument types so that you can overload them with different argument types.
In theory, a compiler could encode the argument types in some other way, but at some level each function body needs to be labelled by (and to have references to it resolved using) both the function name and its argument types. All major compilers certainly use mangling.
Name mangling is unrelated to member functions being virtual or not; after all virtual methods can be called non-virtually just like any member function. Only if the compiler could be certain that a virtual method is exclusively called through the vtable, it might avoid generating any linker symbol at all for the method (just inserting its address in the vtable instead). But I don't think there is any practical way a compiler can know that a method is not being called directly in another compilation unit (as it can for functions that are visible only in the current compilation unit).
extern "C" int func(int *, Foo);
This is from a sample code from class. But I don't understand how the interface is working, one with no variable name, the other with no type. How is that going to work?
When declaring functions you don't need to specify a parameter name, just a type. Foo in this case is a type.
extern "C" tells the compiler it should use a C-style symbol, which more or less means it won't be using name mangling (which C++ uses to allow multiple functions share a name, but use different parameter sets or namespaces).
one with no variable name, the other with no type. How is that going to work?
In the function declaration (and even in definition), variable names are optional, And in your case, Foo is a type, it's not a variable name!
The following program is completely valid even though function f mentions no parameter names!
int f(int)
{
cout << "f(int) is called";
}
int main()
{
f(100);
}
This is a function declaration. You don't need to have a variable name.
The 2nd does have a type, it's Foo.
This is just a prototype. That is to say, it's what's needed to call the function, but not the code that says what the function actually does.
All the compiler needs to know to generate the calling code is the types of the arguments of the function, the function name, and the return type. It doesn't need to know the names of the arguments.
The second argument is a Foo. That's not the name, that's the type.
By using extern "C" you can link a C++ program to C functions.
In your example above, it will turn off name mangling for func so that you can link to code compiled by a C compiler.
C++ compilers need name mangling to differentiate between different functions with the same name. Name mangling is the rule according to which C++ changes function names into function signatures before invoking the linker.
Your assumption is not correct: both parameters have their type specified, and none of them has the name specified. In this case Foo is a type (a struct?) already defined somewhere.
That the parameters have no names is not a problem because this is the declaration of a function: it only serves to let the compiler know the signature (number and types of parameters, plus return type) of the function. It doesn't matter how the formal parameters are named (or if they are named at all). That information is only useful if you are about to write the function body.