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

[Moreland, Kenneth]

Brad,

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.

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      fax:   (505) 844-0833


> -----Original Message-----
> From: vtk-developers-bounces at vtk.org 
> [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Brad King
> Sent: Thursday, December 16, 2004 8:58 AM
> To: Sebastien BARRE
> Cc: ParaView Developers; VTK Developer List
> Subject: Re: [vtk-developers] Removed windows.h from VTK headers.
> 
> Sebastien BARRE wrote:
> > I definitely like less compilation time, but what is the extent of 
> > that change, I mean, how much *hacking* is expected on a 
> decent size 
> > project to make it work correctly with the new change ?
> 
> If the project defines VTK_INCLUDE_WINDOWS_H then it should 
> not need any changes except where it overrides virtual 
> methods defined by VTK.  Only if the project wants to achieve 
> the same compile-time benefit does it need hacking.  To put 
> this in perspective it took me less than an hour to fix all 
> of ParaView.
> 
> There are more benefits than just compile time.  This change 
> also avoids forcing the windows.h mangling on all user code.  
> Not all projects that use VTK include VTK headers in all 
> their source files.  These projects then have problems when 
> VTK headers include windows.h and mangle their own method 
> names in only some of their sources.
> 
> > When I look at Widgets/vtkKWRenderWidget, I'm a little scared:
> > 
> > Instead of a single virtual RemoveProp (which I *know* is 
> overriden in
> > subclasses)
> 
> The VTK/Utilities/Upgrading/FindWindowsMangledMethods.cmake 
> script will quickly reveal any classes that override methods 
> that may have been renamed.
> 
> >         virtual RemoveProp(vtkProp *prop)
> > 
> > We end up with "that" in the .h (and as you said, the RemoveProp is 
> > non-virtual, thus breaking the subclass):
> > 
> > #ifdef VTK_WORKAROUND_WINDOWS_MANGLE
> >   // Avoid windows name mangling.
> > # define RemovePropA RemoveProp
> > # define RemovePropW RemoveProp
> > #endif
> > 
> >   // Description:
> >   // Manage props inside this widget renderer(s). Add, 
> remove, query.
> >   void RemoveProp(vtkProp *prop);
> > 
> > #ifdef VTK_WORKAROUND_WINDOWS_MANGLE
> > # undef RemovePropA
> > # undef RemovePropW
> >   //BTX
> >   // Define possible mangled names.
> >   void RemovePropA(vtkProp*);
> >   void RemovePropW(vtkProp*);
> >   //ETX
> > #endif
> > 
> > [...]
> >   virtual void RemovePropInternal(vtkProp* prop);
> 
> Only the top-most class has to do this.  Subclasses can now 
> just override RemovePropInternal.  The other option is to 
> just rename the method completely to something that does not 
> need this hack but that will break application code that calls it.
> 
> > It's interesting because I remember 4 or 5 years ago we had 
> a lot of 
> > discussons on how to speed up compilation time in the users 
> list, on 
> > Borland and MSVC, and many people suggested solutions. At 
> that time, I 
> > was not at Kitware already, but I wrote a Perl script that would 
> > significantly reduce compile time by detecting the headers 
> that were 
> > most used, in what order, and would create a unique .h that 
> could be 
> > pre-compiled/processed, yadi yada, a hack too which I'm 
> glad did not 
> > make it through actually, but I think it was rejected because it 
> > introduced like... 2 or 3 extra-lines of #pragma in some 
> headers, and 
> > also a global feeling that it was not too good to introduce 
> that much 
> > compiler/system specific code in the source tree...
> 
> It seems feelings have changed as VTK has gotten bigger and 
> compilers have gotten slower.  If you can dig that up again 
> to help us get rid of extra headers in the .cxx files then 
> that would be great.
> 
> -Brad
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
> 
>