[vtk-developers] Removed windows.h from VTK headers.

[Brad King]

Moreland, Kenneth wrote:
> For the clueless (myself included), could you elaborate on the reason
> the virtual functions were renamed?  I don't understand why it is better
> to use a non-virtual GetClassName with virtual GetClassNameInternal than
> to just use a virtual GetClassName.
> 
> Could you also explain what this has to do with windows.h?  You email
> says something about method mangling, but I'm not familiar with any
> method name mangling windows.h did and how that relates to what methods
> should be virtual.

I plan to write documentation on this to include with VTK, but here are 
some links that describe the problem:

http://public.kitware.com/Bug/bug.php?op=show&bugid=836&pos=0
http://aurelien_regat-barrel.blogspot.com
http://arb.developpez.com/vtk/win32

Basically windows.h has a whole bunch of lines like this:

#define GetClassName GetClassNameA

When windows.h is included the method "GetClassName" is invisibly 
renamed to "GetClassNameA".  When VTK used to include windows.h 
everywhere the renaming was universal to VTK and all code that includes 
a VTK header, so the problem was mostly invisible.  However, 
applications that include VTK headers in only some of their sources have 
their own methods mangled and produce linker errors.  Also, if the 
application defines UNICODE then the method gets renamed with a "W" at 
the end instead of an "A" and then linking to VTK libraries gives an 
unresolved symbol.

If VTK does not include windows.h everywhere then VTK gets built without 
the method renaming.  Then when user code includes windows.h before a 
VTK header their call to the method gets renamed and it results in an 
unresolved symbol.

The new approach works around these problems by NOT including windows.h 
everywhere and then making sure all three names (GetClassName, 
GetClassNameA, and GetClassNameW) are defined no matter whether 
windows.h was included or not.  If these three were virtual then to 
override the method user code would have to override all three copies. 
Instead the GetClassNameInternal is virtual and is NOT mangled, so user 
code needs only to override one method.

-Brad