Forward Declaring Py_complex

[Mark Charsley]

In article <slrnai61f5.180.gerhard.haering at lilith.my-fqdn.de>, 
gerhard.haering at gmx.de (Gerhard Haering) wrote:

> In article <memo.20020703144738.2084A at a.a>, Mark Charsley wrote:
> > Is there any way to forward declare Py_complex in C++ headers? 
> 
> #include "complexobject.h" should do the trick.

Hmmm, my system also needed

#include <stdio.h>
#include <python/pyconfig.h>
#include <python/object.h>

before complexobject.h.

> > I'm trying to create a C++ function that returns a Py_complex, and 
> > would
> > really prefer not to have to pull in all of Python.h in the header 
> > file.
> 
> Any reason why? I can't think of any good reason.

Compilation times. There are a lot of clients using the C++ class with the 
Py_Complex-returning member function. Many of them don't need to use the 
function at all, and those that do don't care about any python objects 
other than Py_Complex. As such if it's possible to say "a Py_Complex is 
just a struct with two doubles" or even "look, there's a struct called 
Py_Complex, kicking around that most of you don't care about. Those that 
do ought to look up it's details later, those that don't just take my word 
for it, and don't treat it as a syntax error" then I can avoid having to 
force all my class's clients from having to pull in a lot of header files 
that most of them don't care about. This will have two benefits:
1) build times won't be hit by having to process unnecessary headers for 
each cpp file
2) my workmates won't spend the next week moaning that I've broken their 
build and asking which directories they have to put in their project's 
include path to fix it.

1) I can live with, 2) is something I'd rather avoid :-) At the moment 
I've avoided the problem by having a tiny wrapper class I can 
forward-declare, but it would be nice to avoid having to copy the doubles 
between my wrapper class and a Py_Complex.


-- 

Mark - personal opinion only, could well be wrong, not representing 
company, don't sue us etc. etc.