[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4