[vtkusers] VTK-Win32 problem only : including vtk includes windows.h

[Ken Martin (Lists)]

The defining of things such as GetClassName, Window, etc by windows.h (and
for that matter X as well) is a disaster. Having said that it is difficult
to not include them everywhere. For example if we didn’t include windows.h
in the header files but included it in the cxx file then the cxx file would
try to call or implement GetClassNameA but the header file would have
declared GetClassName. While VTK could probably hack its way around these
problems, very quickly we would run into user’s code that does

 

#include <windows.h>

#include <vtkFoo.h>

 

and then the user would get lots of undefined references, etc. This is a no
win situation. The best solution is to avoid using any names that are
#defined by common libraries such as X and windows. (which is why we have
ColorWindow and ColorLevel instead of Window/Level in many classes)
unfortunately we caught onto this too late and are stuck with it. As I’ve
done more windows development I’ve found that life is generally much easier
if you bite the bullet and include windows.h. Not just because of this issue
but there are other issues you can bump into as well.

 

Thanks

Ken

 

 

Including VTK headers includes windows.h which is a problem for me.

I have some #define conflicts (just an annoying compiler warning) but also a
more serious issues. For example, some of my classes have a GetClassName
method, as VTK does. This is changed to GetClassNameA as GetClassName is a
macro defined by including windows.h.

I have some strange behaviour with my app which I am porting from Linux. I
suspect this is the main problem.

I think that it is not a good thing that using VTK causes the inclusion of
windows.h

This should only be done by the internal of concerned VTK classes (few .cxx
files) and windows.h should not figure in vtkWin32Header.h.

What's your opinion ?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20040511/7e6b3073/attachment.htm>