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

[Matthias Baas]

Roman Yakovenko wrote:
> 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 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.

Uhm, I didn't see any finalize() method anywhere...?
By "class code creator" you probably don't mean the object I create with 
module_creator.creator_t(), right? Then how do I obtain the class code 
creator that corresponds to my particular class?

>> 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. [...]
> 
> 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. 

Why don't you just include the header that actually defines the 
corresponding class (i.e. "a.h" when wrapping A and "b.h" when wrapping 
B)? If a header depends on other stuff the appropriate #include 
statement has to be in that header anyway (in the above example, b.h 
does already include a.h).
In my case, I have to add some headers manually because Boost.Python 
requires the full definition of a class whereas the original headers 
only contain forward declarations. But that's ok with me.

>> (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.

Do you generate the bindings on a local drive or on a network drive? 
Maybe performance could become an issue once the data has to be 
transferred over a network...?
By the way, an alternative to comparing the entire file could be storing 
a checksum (such as CRC32, see zlib.crc32()) somewhere at the top of the 
file and comparing only that value.
But so far, this is really a minor issue. If I get the above header 
thing sorted out, the current performance is good enough for me (and I 
am already on a network drive).

>> 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. :-(

No problem, it's only a warning anyway (and actually, I don't understand 
why gcc insists on that newline...).

>> 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 don't think it's a bug in pyplusplus, it's just that those protected 
methods use a class whose full definition is not available. For example, 
there's a protected method 'void setPtr(MPtrBase*);' and a full 
definition of MPtrBase is not available, the header only contains a 
forward declaration. When compiling the bindings I then get the error:

.../type_id.hpp:71: error: invalid use of undefined type `struct MPtrBase'
../MObject.h:94: error: forward declaration of `struct MPtrBase'

>> 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.

Does that mean my above filter won't work anymore (as it would produce 
'empty' classes) and I will have to return True when called on the 
actual class methods? (and if so, how would the updated filter look like?)

- Matthias -