[C++-sig] (Fwd) Previous email to Nicodemus

[Niall Douglas]

On 3 Aug 2003 at 13:06, Nicodemus wrote:

> Yeah, I didn't got this email before. 8)
> Thanks for sending again.

It seems then that there's something wrong with email between us. 
Maybe your email system thinks I'm spam? ;)

> > However, the latest version still has the problem with passing
> > backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the
> > precompiled binary off its web site).
> 
> Yes, GCCXML expects forward slashes only. Does this trouble you?

Absolutely. On Win32 GCCXML dies a very horrible death if there is a 
single backslash in its command line. Since pyste takes backslashes 
in its input off its command line, this creates a problem eg; me 
passing command line variables to pyste which obviously would contain 
backslashes.

Why on earth couldn't DOS just have taken normal slashes! :(

> Hmm, I see. There's no documentation avaiable for GCCXML, so it is
> kind of a mistery to predict all the weird names that it assigns for
> unnamed enums. 8) Thanks!

Not really. GCC itself allocates temporary symbols starting with $. 
That's why you can't use $ in your own symbol names on most systems. 
You can see plenty more if you investigate the embedded assembler in 
GCC.

> > Next extension: my .pyste file is actually a full blown script which
> > reads the contents of a directory for the header files and then
> > dynamically creates the variable = AllFromHeader(filepath).
> 
> Nice. That's an advantage of they being python scripts. 8)

It's why python's great! I haven't had so much fun programming in it 
since BBC Basic V on the Acorn Archimedes (a wonderful system for its 
day)! A marriage between my C++ and python environments would be 
ideal ... at least till I get some time to write the lazy functional 
language I've always wanted to write (Haskell's too esoteric).

> I see your problem, but I find the solution kind of a "hack". Have you
> tried if sys.path[0] gives the directory where the pyste file is? If
> it doesn't, I think we will have to use this solution, but I prefer
> following the upper-case conventin for constants:

Err, doesn't sys.path refer to the script which invoked python? I 
think so. Anyway, anything execfile'd is considered not standalone as 
far as I understand ie; it merely reads the file into a string and 
compiles that to a code object ie; it's no different from exec. 
Anyway I've not tried it, and don't have enough experience with 
python to say for sure, so I'll shut up now :)

> > Next point: pyste seems to want inherited members return policy set
> > for each and every subclass. So if I bind FXWindow and FXTopWindow
> > which inherits FXTopWindow, I must reapply set_policy() for all
> > FXTopWindow's inherited methods from FXWindow.
> 
> I think you mistake the classes in this example. Could you clarify?

class FXTopWindow : public FXWindow // in FXTopWindow.h
{
	FXObject *foo2();
}

class FXWindow // in FXWindow.h
{
	FXObject *foo();
};

If I do AllFromHeader on FXTopWindow.h, it pulls in all the base 
classes of FXTopWindow (correctly) and then asks for you to set the 
return policies of foo() and foo2().

Now if I'm also doing FXAllFromHeader on FXWindow.h in the same pyste 
file, it'll want a return policy set on foo(). My point is that if 
you've already set the policy for foo() in FXWindow, you also set the 
policy for all inherited versions of foo() in all subclasses of 
FXWindow (because apart from covariant return, return types must stay 
identical in overloads in C++). Therefore you shouldn't need to set 
it again (except that pyste does actually want you to).

Cheers,
Niall