Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / COM and name mangling Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Brent Arias

April 13, 2005, 01:06 PM

I'm reading Don Box's "Essential COM" and he explains "The virtual functions of a (COM) interface class are always called indirectly via a function pointer stored in a vtbl, without requiring the client to link against their symbolic names at development time. This means that the interfacemethods are immune to symbolic mangling differences between compilers" (p21).

Despite having read all of his explanatory material, I don't see how this can be true. For example, look at this simplified version of making a COM-ish like call:

  1.  
  2. #include "ifasttring.h" //just some COM thingy for demo purposes
  3.  
  4. int f(void) {
  5.   int n = -1;
  6.   IFastString *pfs =  CreateFastString("Hi Bob!");
  7.   //Just arbitrarily call some method on the COM-ish DLL.
  8.   if (pfs) {
  9.     //UH OH!!! Doesn't this "Find" require symbolic name resolution at link time?
  10.     n = pfs->Find("Bob");
  11.     pfs->Delete();
  12.   }
  13.   return n;
  14. }
  15.  


Somehow the compiler for the client code above must "lookup" the Find() method's entry in the vtable, which presumably requires symbolic (or "name mangled") resolution at link time. So I don't get it. Why does Don Box insist that the call 'pfs->Find("Bob")' avoids the symbolic linking issue?

-Brent

 
I'M BRIAN FELLOWS

April 13, 2005, 01:26 PM

__DECLSPEC(NOVTABLE)

 
Chris

April 13, 2005, 01:33 PM

The virtual functions are looked up by their index in the vtable. It is sufficient that both sides assume the same ordering of the functions.

 
Brent Arias

April 13, 2005, 02:14 PM

Ok, so if I understand you, the client knows all the calleable virtuals, because those are declared in the IFastString.h file, and when when Find() is called, it assumes an index (based on what the client's compiler saw in IFastString.h) that is (thankfully) the same as what the DLL's compiler had established.

 
Chris

April 13, 2005, 04:09 PM

Exactly.
If you changed the header file in between, things would go astray.

Brian Fellow's __declspec(novtable) is a MSVC trick to reduce the class size.
If you have a class whose virtual functions are all pure virtual, you can omit the vtable, because it'll be provided by the descendent class, which saves you 8 bytes or so.

That's also the reason why different languages cann access the classes.

For example you may know Borland's Delphi. You can declare a class with virtual functions in C++, give Delphi a pointer to an instance of that class, and imitate the C++ class declaration in Delphi.
Then you can call the function even though Delphi has absolutely no understanding of the C++ name of the function. It simply looks into the same vtable index.

 
This thread contains 5 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.