Dear forum members,
I know that not anyone of you is paid for providing help to other C++ users, I know that most of you do not have much time to spend on this forum, I know that it is very hard to be concentrated after a full-day work especially when the topic is a tricky one like this and when reading very long posts like my first post in this topic, and I know that all of you have other duties as well but please be concentrated when you read other people's posts and most of all be precise if you decide to answer. I am not always right when I make assumptions but I always do my best to be clear and precise. Reading your answers I have a very strong feeling that not anyone of you has carefully read my posts (thus didn't understand the problem or what I said) and above all you give contradictory answers. So if you decide to participate in a topic please be concentrated and precise.
|Both statements are true: There is one vtable for T in each translation unit where T is odr-used. Since they are emitted as defaulted weak symbols (you can see that with nm on Linux), there is one vtable for T in the linked program. Translation units do not exist after linking.|
First these are not statements
so they cannot be true. Second, my questions asked whether VFT information for a type is used in a program as multiplied copies in many object modules in which case the program would not rely on assistance from linker, or as one global data structure in which case the program depends on assistance from linker. These obviously exclude each other so they cannot be both true.
Since Cubbi actually checked the object files generated by the compiler I will trust his answer. His answer implies that my assumptions I made in the Solution_2 that I wrote in the section POSSIBLE SOLUTIONS of my first post are true. I will not repeat myself but I will just point to the most important implications I wrote there:
- assistance from linker is needed since there would be one global VFT for each polymorphic type that would be accessed by the code in different modules but as I said there is no need to extend the linker with a special feature just to support polymorphism. However as I said there the compiler would create special "hidden" global variables that would represent VFT's that would not be visible in the source code but would be visible to the linker as symbols in the import/export sections of the object files.
- I asked there where (in which module) would compiler decide to define
a VFT for a type (put the VFT symbol in the export section) and where to declare
it (put the VFT symbol in the import section), and I made a possible answer. Any comments on that?
|To the virtual table of C, since the object is a C, and C is the last class in C's inheritance tree that contains virtual functions. |
|It's pointing to the C object. Within the C object there is a pointer to C's VFT. The main function doesn't know any of that, it treats it exactly as it would treat any T object. |
Since both helios and Cubbi have the same answer I will proceed from that. This returns us to the very beginning of the problem and the question I asked on Jan 23, 2016 at 9:01pm:
|Can you explain to me how the code in Source2 can "parse" VFT of a dynamic child type that it is not aware of and that is defined only in Source1? The code in Source2 has to find a virtual function's position in the table. The generated code in Source2 has to somehow extract part of the dynamic child type's VFT that corresponds to type T of the function's F return type. But how can it extract that part if it does not know anything about the structure it is extracting from?|
In other words: The code generated from Source2 does not know anything about C since it is not defined there. Yet, according to both helios and Cubbi it will receive a pointer to the C object that has a pointer to a global VFT of C. But the code in Source2 does not understand
(does not know the structure of) VFT of C. So how can it find where in the table is fT?