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

[John Biddiscombe (CSCS)]

Couldn't we
#include "vtkWindows.h" which would simply include windows as usual and 
then #undef all the clashing names that are causing trouble.
If users are then having trouble calling windows functions because of 
their removal, they can
#include "vtkWindowsUnMangle.h ....." which will redef the undef'ed 
methods. Not many users will be calling the windows functions that are 
renamed and they can easily insert #ifdefs in their code without vtk 
having to be bludgeoned into conformance

JB


Brad King wrote:

> 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
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>

-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82