Murray Cumming has created the basic skeleton for the C++ bindings as part
of the gnomemm project (gnomemm module in CVS, gnomemm/libgdamm). So, as
we've got the C++ bindings in the libgda source tree very outdated due to
the big changes in the C API, we should be taking advantage of the work
Murray has done.

From my conversation with him on IRC:

<rodrigo> so, what do you need for libgdamm?
<murrayc> Hi rodrigo. We need people to go through all the classes, adding
*.hg/*.ccg files, and adding wrapper lines for the methods, signals, and
properties.
murrayc> And to add any examples that are currently in libgda.
<rodrigo> so, is that a 'by hand' process, right?
<murrayc> There's a small learning curve for people who aren't familiar
with gtkmm, but it's quite simple really.
<rodrigo> (ie, as you said there were some scripts)
<rodrigo> oh, yeah, I can't understand gnomemm directories :-(
<murrayc> rodrigo: Well, it's partly by hand. Lots of the code is
generated, based on a list of conversions and the .defs files that I have
already generated from your libgda headers.
<murrayc> rodrigo: There are docs on gtkmmproc in gtkmm. But you can see
the general idea in libgdamm/gda/src/connection.hg.
<rodrigo> hmm, I suppose you're wrapping libgda HEAD, right?
<murrayc> rodrigo: Yes. Is that sensible?
<rodrigo> yes, that's correct
<rodrigo> I don't want you to lose any time in the GNOME 1.4 version
<murrayc> One or 2 people have expressed interest in gnome-db C++ bindings.
I'm hoping that they will help out. It's low priority for me at the moment.
I like to get things started so that other people can continue them.
<murrayc> rodrigo: Yes, GTK1.2/GNOME1.4 is boring ancient history.
<rodrigo> in fact, we were planning on doing the .defs files for generating
bindings for many languages
<rodrigo> so I guess we can reuse the ones you did
<murrayc> rodrigo: Yes. I used h2defs.py and our own signals defs
generator, but I had to remove some ORBIT_* functions because they weren't
parsed properly.
<rodrigo> ok
<murrayc> rodrigo: In practice, we all use the same .defs generators but
end up having slightly different .defs files.
<rodrigo> so, it is in libgdamm/libgda/src that I should add the ccg/hg
files, right?
<murrayc> rodrigo: Yes.
<murrayc> rodrigo: me, cactus, and danielk are very familiar with the
.hg/.ccg system. Others know about it too.
<murrayc> rodrigo: It gets _slightly_ more complex when dealing with boxed
types or raw structs. But you can leave them as C types until you
understand how to wrap them. We can wrap them though.
<rodrigo> ok, I'll ask you then :-)
<murrayc> rodrigo: So you have an interest in C++, or only for libgda?
<murrayc> rodrigo: I meant to start wrappers for gnome-db after I heard
about them at GUADEC2. Then I waited for the big GObject change. Then I was
reminded by your talk at GUADEC3.
<rodrigo> I'm interested in having libgda in many languages, not only C++
<rodrigo> but C++ has been the best supported
<rodrigo> the only complete binding in libgda so far
<rodrigo> although for GNOME 2, it's outdated, since we did many changes in
the C API
<murrayc> GObject is difficult to wrap, due to lifetime issues.
<rodrigo> oh
<murrayc> But we solved it.
<rodrigo> cool
<rodrigo> that's why I don't understand the source code in connection.hg :-)
<rodrigo> those macros are what solves the GObject issues?
<murrayc> rodrigo: Well those macros result in generated code, or give
information about code that will be generated. Then all C++ classes are
used via the RefPtr<>. See http://gtkmm.sourceforge.net/gtkmm2 for a link
on memory management, or see the RefPtr bits in here:
http://www.murrayc.com/murray/talks/2002/
<murrayc>
http://www.murrayc.com/murray/talks/2002/GUADEC3/slides/html/img10.htm