Neal Norwitz <neal@metaslash.com> writes:
> On Fri, Oct 11, 2002 at 07:48:52AM -0400, Guido van Rossum wrote:
> > > > 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?
> > >
> > > I think they cannot possibly be included multiple times in a correct
> > > application, since a correct application does not directly include
> > > them, anyway.
> >
> > But that's true of any .h file that's included by Python.h, isn't it?
> > And there's only a handful of .h files that Python.h doesn't include...
>
> I don't really think there is much to be gained by adding protection.
> It's unlikely the files would be included directly by an application.
> Even if the files are included multiple times, the worst that should
> happen is a redefined warning.
Ahem. Don't forget that C++ applications may need to read these
files. The rules about redefinition are different in C++ IIRC.
So, if these files /really/ don't need to be #included directy by an
application, that's fine...
However, I note that Boost.Python has to #include <patchlevel.h> because
we have to apply workarounds before #including <Python.h> for certain
versions of Python, so I wouldn't say that it's very unrealistic to think
applications might need these files separately.
--
David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com
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