[Kde-bindings] Refactoring kalyptus

[Luca Fascione]

I'm not sure that loosing the macro names would be a smart idea, though...

I mean, I did know that you could cpp (i.e. gcc -E) the headers, but for 
example the following

class yadda {
    public slot:
       int aFunction() {/* ... */}
    public:
       float anotherFunction() { /*...*/ }
}

would become

class yadda {
    public:
       int aFunction() {/* ... */}
    public:
       float anotherFunction() { /*...*/ }
}

and I remain uncertain whether you want to pay that price (and a number 
of similar ones) to save on macro expansion...

Might still be wrong, though...

Luca

Caleb Tennis wrote:

>Hi,
>
>I know there was some thoughts and talk about 6 months ago on smoke 
>refactoring and reworking for the Qt4 bindings.  One thought I had on the 
>subject was to use gcc's preprocessor dump to handle the #defines and #ifdef 
>stuff that kalyptus tries cleverly to muddle through.
>
>It looks like just doing a "gcc -E" on a header file, provided all of the 
>#includes are met, will preprocess the file automagically.  This might cut 
>down on some of the ambiguity and overhead that smoke and kalyptus go 
>through.
>
>Anyone have thoughts on this?  Am I way off on my thinking?
>
>Caleb
>_______________________________________________
>Kde-bindings mailing list
>Kde-bindings at kde.org
>https://mail.kde.org/mailman/listinfo/kde-bindings
>  
>

-- 
Luca Fascione
Pipeline Engineer - Weta Digital

+644 380 9815 (x4904) / +64 21 0764 862