[Python-Dev] Re: Multiple Inclusion of Header Files (original) (raw)

Fran�ois Pinard pinard@iro.umontreal.ca
Thu, 10 Oct 2002 23:28:02 -0400

[Guido van Rossum]

From SF #607253, header file problems ( http://python.org/sf/607253 ) is there any reason why these files: graminit.h patchlevel.h pyconfig.h (aka pyconfig.h.in)

don't protect against being included multiple times? ie, they don't have: #ifndef PyFILEH #define PyFILEH /* ... */ #endif /* !PyFILEH */ Could've been an oversight. I notice that graminit.h and pyconfig.h are generated files. patchlevel.h was originally a one-liner. Is there anything that is gained by adding those?

I never have been comfortable with the trend of recent years about include files protecting themselves against multiple inclusion, which progressively replaced the previous trend about including more carefully than blindly.

Granted, the wild variety of organisations for include files in various operating systems is a problem in itself, writing portably in that almost intractable mess is undoubtedly a challenge. Protection against multiple inclusion has been welcome in that area.

However, this habit of protection is spreading (I might even have given into it myself) and I sometimes wonder if we do this is by mere mimetism, or for any good reason. We are loosing possibly useful clues when programmers include uselessly, or design poor hierarchies for their include files.

It now goes a bit far. I was surprised to discover that even Bison adds such protection to the `.h' files it generates, I do not believe there ever was a problem. Python does not exist in such a multiplicity of hierarchies that one is hopeless to ever include properly. So, we could ask ourselves if auto-protection is really meaningful for Python header files...

-- Fran�ois Pinard http://www.iro.umontreal.ca/~pinard