[C++-sig] pyplusplus tutorials & GUI wizard

[Roman Yakovenko]

On 2/1/06, Matthias Baas <baas at ira.uka.de> wrote:
> Thanks for fixing that. With the latest cvs, the noncopyable and no_init
> specifiers are added, but on Linux (using gcc) it still doesn't compile
> because of the *_wrapper class which is derived from the original class.
> I still get an error message that the destructor is private. I suppose
> in this case, such a *_wrapper class wouldn't be required anyway and the
> original class could be wrapped directly. Can I somehow suppress the
> creation of such wrapper classes?
> By the way, on Windows (using VC7.1) the code compiles without
> problems....?!

I did not test my changes with GCC. I will test them. As a temporal solution
you can remove the wrapper code creator. Try to use finalize method on
class code creator.

> >> Now I also noticed another thing that'll get more serious the more
> >> classes I wrap. Whenever I create the source code for the bindings
> >> (using the multiple_files feature) *all* files are recreated, even when
> >> the actual contents is the same than before. When I then compile the
> >> module (using distutils) *every* file is recompiled which will take
> >> quite some time once I've wrapped the entire SDK (which has about 300
> >> classes). Is there a way to tell pyplusplus to only generate a source
> >> file when the contents will be different from a previous run?
> >
> > I will fix this.
>
> Basically, it works, but there is still a problem. Whenever I add a new
> class there's a new header file that gets included into *all* files
> automatically which wouldn't be necessary. So the files still change and
> get recompiled. I don't know how pyplusplus determines the files that
> it'll include in the output but I hope that there's a way to include
> only those header files that are really required.

The problem is that I ( pyplusplus ) can not build set of required files.
Consider next case:
file a.h
  class A{};

file b.h
  #include "a.h"

  class B{};

You want to export A and B. pyplusplus will generate include to a.h
and b.h. While
writing those lines I think that I found solution, but requires
modification of pygccxml.
I am not going to implement this for next release, but still
pyplusplus provide nice way to solve this situation.

TnFOX has one header that include all other header files. Before
generating code,
we modify extension module. We remove all includes for TnFOX and replace them
with include to main header.

Here is relevant code:
#extmodule defined somewhere
includes = filter( lambda creator: isinstance( creator,
code_creators.include_t )
                        , extmodule.creators )

includes = includes[2:] #all includes except boost\python.hpp and
__array_1.pypp.hpp
map( lambda creator: extmodule.remove_creator( creator ), includes )
extmodule.adopt_include( code_creators.include_t( header="fx.h" ) )

> (Just out of curiosity, how do you determine whether a file has to be
> written or not, do you really compare the contents of the existing file
> with the data you're about to write?)

Yes, this is the only way, that I know, that does it reliably.
Don't warry about performance. It takes only 90 - 100 second to create\generate
Boost.Python bindings for TnFOX, 625 files.

> By the way, after the cvs update I got a new warning from gcc. The
> compiler complains that the last line in the generated source files
> doesn't have a newline.

Next time before I do check in I will check it first on Linux. Sorry
for inconvinince. :-(

> Then there's a new thing that came up. Pyplusplus also adds protected
> methods to the generated wrappers which breaks compilation for me. How
> can I disable that feature?

Right now there is no way to disable it. Could you send me simple test
case that breaks
your compilation. I tested this behaviour and it works fine. Also if I
fix this bug, do you
still need to be able to disable this feature?

> I thought I could just filter them out, but then I noticed something
> else that I don't understand. I already have my user defined filter
> function that filters out everything but my desired classes. The
> function basically looks like this:
>
> def filter(decl):
>      return decl.name in [...<a list of class names>...]
>
> But now that I come to think about it, I don't understand why this works
> at all. I noticed that the filter function is also applied to class
> methods in which case the function returns False. But why are the
> methods then exposed? (I thought this would be a way to filter out the
> protected methods, but obviously this is not how it's supposed to work...)

You found a bug. Thanks. I will fix it.

> - Matthias -

Thanks for bug reporting

Roman Yakovenko