[Paraview-developers] Removed windows.h from VTK headers.
Brad King
brad.king at kitware.com
Wed Dec 15 10:11:03 EST 2004
Hello all,
I have committed changes to VTK that completely remove windows.h from
most of its headers. This addresses bug #836. Documentation of this
change is available in
VTK/Utilities/Upgrading/FindWindowsMangledMethods.cmake.
Since many files were changes I will not report their individual
revision numbers. The CVS tags surrounding this change are:
VTK-RemoveWindowsH-pre
VTK-RemoveWindowsH-post
This change results in a 70% compile time reduction on Windows
compilers because the compiler does not have to parse the 280K lines
of source the preprocessor produces from windows.h. Only a few OpenGL
and Tk headers in the Rendering directory and
Common/vtkCriticalSection.h still include windows.h, and these may be
removed in the future. All VTK code that still includes windows.h
does so through vtkWindows.h which includes a minimal part of the real
windows.h header.
In order to avoid the windows method mangling problem all three
possible names for such methods (Foo, FooA, and FooW) are provided
using a preprocessor trick. Users can detect places in their own code
that may need this trick by using the cmake script
VTK/Utilities/Upgrading/FindWindowsMangledMethods.cmake.
There are two backward-compatibility issues:
1.) User code that used the windows API without including windows.h
that worked before because VTK included it will now break until the
explicit inclusion is added. This is considered acceptable because
the code was technically wrong in the first place. As a quick-fix,
users can define VTK_INCLUDE_WINDOWS_H in their application and VTK
will include windows.h as it did before.
2.) A few virtual functions in VTK were renamed and replaced by
non-virtuals that forward their calls to a virtual internal
implementation. User code calling these methods will not be
affected. User code wishing to override these methods in a subclass
will have to rename to the internal name. Such user methods will
also be exposed by the above mentioned CMake script. The most
common such method is GetClassName, which has been renamed to
GetClassNameInternal. Since user code is supposed to define this
method by using vtkTypeMacro or vtkTypeRevisionMacro, this should
not be a problem.
Currently ParaView is depending on VTK_INCLUDE_WINDOWS_H to build, but
only a few changes are actually needed to fix it. I plan to make these
changes soon and then the compile time of the whole application on
Windows should get this benefit also.
-Brad
More information about the Paraview-developers
mailing list