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

[Nicodemus]

Niall Douglas wrote:

>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? ;)
>  
>

No, I don't think so... but I'm sure I didn't got it (just searched in 
my inbox).

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

I see. No problem, Pyste can be made to convert automatically 
backslashes to forward slashes. 8)

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

You are right. Any name starting with $ is certainly an internal name.

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

Yes, I have this feeling too. But the merriage you propose between C++ 
and Python is already possible: we have been using it with great sucess 
at our company.

>>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 :)
>

You are right... it was just a guess. I didn't test because I was not at 
my computer at the time. I guess a variable named INTERFACE_PATH in the 
pyste file's namespace is good enough then. 

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

I couldn't reproduce this problem, actually. If you do an AllFromHeader 
in FXTopWindow, it should only complain about the lack of policy for 
FXTopWindow.foo2, since FXWindow won't be exported at that time. In 
other words, only when a function is about to be exported the check for 
a policy is made. But if instead of "foo2()" in FXTopWindow you meant 
"foo()", then I see the problem. 8)

Regards,
Nicodemus.