[Python-Dev] Re: Multiple Inclusion of Header Files

[François Pinard]

[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 Py_FILE_H
>>     #define Py_FILE_H
>> 
>>     /* ... */
>> 
>>     #endif /* !Py_FILE_H */
>
> 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