RE: [gtkmm] Glib::Module API issues

[Murray Cumming Comneon com]

> From: Ross Burton [mailto:r burton 180sw com] 
> I'm using Glib::Module to load C++ objects from .so files at 
> runtime --
> the good news is that it works.  However, there appears to be 
> a problem
> with the wrapping.
> 
> The C API is:
> 
> GModule* g_module_open (const gchar *file_name, GModuleFlags flags);
> 
> Returns a GModule*, or NULL on failure.
> 
> However, the C++ API:
> 
> Glib::Module::Module (const std::string& file_name, 
> ModuleFlags flags);
> 
> If I use the constructor directly, I can't have a null GModule on the
> stack. If I use new, then I don't seem to get a null pointer even if I
> try and load a module which doesn't exist.

I suppose we should throw an exception, but constructors can't do that (I
think) so we could add an operator=() instead. That would be like using a
std::fstream, I think. In the meantime if(module.gobj()) might be an
equivalent to if(module).

> I've compared module.hg and gtk/window.hg, and the way they 
> declare the
> constructor wrapping is totally different.

Yes, because GModule isn't a widget. It's not even a Gobject.

If you don't understand the wrapping code, it's OK to look at the generated
code and talk about that. Someone else might be able to tell you how to
write the gtkmmproc code to get the desired output.

> Of course, not 
> being a gtkmm
> wrapping wizzard, this could be intentional. But as 
> Glib::Module isn't a
> commonly used class, I guess this sort of bug could have gone 
> unnoticed.
> 
> So, is there a bug in the wrapping? Or am I going mad...

You are probably the first to use it. I wrapped it so that someone would try
to use it and show us the bugs, but nobody did before the freeze. Maybe you
could provide a patch for glibmm 2.4. It would be even better to have an
example in glibmm 2.4 so that we could prove that it works.

Murray Cumming
murrayc usa net
www.murrayc.com