Review the THIS pointer
Here are the conclusions discussed on other BBSs in other BBSs, and it is also the content of notes 8. I didn't read the book these days. Oh :) First, in the 32-bit operating system, the pointer occupies 4B, (huh, I think everyone knows, nonsense), so P1 is in this 4 position. Second, the THIS pointer in note 5 does point to the hidden parent class A, this parent class can be said to be the parent class in B. A re-VC compiler and WIN operating system, B and his implied parent class It is the same, that is, this
The pointer also points to B itself. Then, the reason why the pointer calls AAA is B, instead of him implies the parent class because only only in the VFTABLE
A virtual function, that is, the one in B, and VFTABLE is also the same as the above, as for VFTABLE
, I believe those men who are not playing a small skill, I also stepped away! Finally, this is the location of this virtual function. He is in the stack, or in the stack? The answer is in the code segment, as for how to address it, you don't know!
Then the array variable (object) exists in VC and WIN, the four cases of the existence, namely: Stack, Heap, Global, Local Static, there is reason to believe in Global, Local Static (a family), That is to say they are allocated in the same memory area, or their address is continuous. And Stack and HEAP are their respective independent memory. Take them as a, b, and c memory, respectively (in the order described above). So what is the variable being assigned in that memory? 1) Global variables, static variables (remove New Generated) in a zone; 2) The variable of global new and the variables generated in the main () internal or function in the C zone; 3) function, main () Internal, class member variables are located in the B zone; 4) functions, class member functions (unrelated to virtual facts) are located in the code segment, as they are addressed, I haven't made it! (A family!) Oh, no!
Conclusion The existence of variables (objects) has finally clear the so-called addressing problems in 9, so it will be described here. To talk about this problem, it is actually telling the so-called Win32 PE file format, which is actually designed to Dumpbin, so even reached N times! :) In the Debug version, you can find it, in fact, EXE If there is no DLL, huh, huh), there is a global variable and local static variables, as well as a so-called string, and the local variable is loaded into a thread's stack, said in 9. The .BSS block is an initialized global variable and a static partial variable. However, I debug, I found that the above: 1) The above-called initialization and unencured problems, it seems that it is not obvious in VC, that is, they (initial sum) seem to be interlaced with each other, jade RAM In, and there is jumping. Not why? 2) The so-called addressing problem (9), is said to be (whose reason is said, because I don't actually go to Dumpbin, and I am very hard to say! :), I have time to study, then tell us, Oh !!) is to address the call [xxxx] in the .idata block, XXXX is the function address, so it seems that this address is not found when Debug is. 3) As for the file format of Win32 PE, I COPY a piece, but I didn't belong to others' name, I just took my own next article, after all, it was an exquisite, there is no complete copy! Moreover, my topic is also a note, huh, huh, save everyone's time. I saw that I found to tell everyone, huh, huh, I hope you are interested. Finally, in fact, this conclusion has no conclusion, but this topic is too hurtful, and it is expensive! :) Good things, make aware (all nonsense! :)) VC includes two versions: Debug version includes debugging information, so much more than the release version (possibly large hundred k to number m). As for whether DLL support is required, mainly look at the compilation option you use. If ATL is based on ATL, the debug and release versions are similar to the DLL. If the compilation option used is to use the MFC dynamic library, you need MFC42D.DLL support, and the Release version requires MFC42.dll support.
