GTK-CC
The GTK-CC
is a small perl-skript that transforms header-files that
look like those from the GTK+ system. These
are object-oriented declarations written in plain C. For any C
header source the output of GTK-CC
works just like the original
because the GTK-CC
will only add a few lines inside #ifdef __cplusplus
.
The additions are just some C++ inline-methods inside the structure
declarations, and the use of the C++ inclusion/inheritance
syntax for the base type of each of the structures (again #ifdef __cplusplus
).
As a result, the enhenced (GTK) headers are much more easier to use from C++. For the one thing, a C++ compiler does know now about the inheritance relations for the structures, so you can leave off the ubiquitous big-caps cast-macros - instead you will benefit from compile-time type-checking as is builtin each C++ compiler.
For the other thing, you can use the (GTK) procedures as inlined methods
along the defined objects. Your code will become much shorter - and
in consequence more readable and maintainable. And you don't have to
think about which base-type had been introducing the set_border_width
method - you can just call the method of that object instance (or their
class-scope static-declared counterpart that is also generated).
Unlike real C++ wrappers, like GTK--, the object size will not increase by a single byte. No additional library needs to be linked in, so even the runtime footprint is the same. And if you don't have a C++ compiler at hand (huh?), you can start rewriting the C++ code in an incremental way because the methods are directly derived from their underlying C-language procedure names. Since the very same headers can be used with a C compiler you will end up at just changing the file extension and it will compile cleanly.
If you want to add another function you can always switch back to C++ mode, make a RAD implementation, and if you're done you can rewrite it back into plain C. Nothing could be easier. It does help me a lot in my GTK developments - and I don't need a real wrapper bloatware (for C++/GTK or even Perl/GTK).
The GTK-CC
is nothing more than a simple perl skript that should
(currently) be run in the directory of the GTK headers. It will then
create a directory named ../gtk+
and put all the transformed
headers in there. It will even change the inclusions from
<gtk/*.h>
to <gtk+/*.h>
.
So what you want to do is
gtk-c-to-cc.pl -q *.hwhere the "-q" options means quiet. There are some other (not yet documented) options, just look into the source and try for yourself. This is currently nothing more than a quick hack which serves me well in my GTK developments.
The script can probably be adapted to other C-language object-oriented library systems - apart from two points the script does not make any other assumption on the headers, well other than the naming scheme should be similar to that as used by GTK.
For now, it may give you a /usr/include/gtk+
sister directory
for your /usr/include/gtk
directory if being run inside of
the latter.
You can get the latest perl script from here, it is called pub/gtk-c-to-cc.pl and you may find updates in the local pub directory.
From GTK Tutorial Example 3 (shortened, no comments here) | |
| |
And the same section in C++ mode (using <gtk+/gtk.h>) | |
|
main
init routines.
This wrapper does not even make use of the C++ allocators
(new/delete), so all objects can be just fed to any other
C routine around.
GTK-CC
does currently generate the methods with an
additional underscore attached to the end. This is semi-optimal I'd say.
If this script would become a standard GTK thingie then the GTK
developers would surely care for choosing member/methods names that
don't clash in C++ mode.
GTK-CC
skript does not give you anything on this account.
GTK-CC
: if an object-method returns void
then the first argument is returned by the generated inline code. That is why
show_ ()
works on button
, and not the box.
int
s and pointers will have a "= 0"
and
gboolean will have "= TRUE"
. Now look again at the example
above and count the args you don't need to put in... (I am not
in favour of this solutions since it will make it harder to backport
the sourcecode to plain C).
(C) Mar'00-Apr'00 |
GTK-CC
| e-mail:guidod@gmx.de |