Re: Tricks of the trade

[Murray Cumming <murrayc murrayc com>]

On Wed, 2005-02-23 at 16:04 +0000, Russel Winder wrote:
> Jan,
> 
> > First of all, you should get a backtrace to see which part of code
> > causes that message. The message is going through function g_logv, so
> > you can put a breakpoint on that and get a backtrace when it's hit.
> 
> Thanks for this tip, most useful.
> 
> It turns out that g_log was the procedure being used in this instance
> (thanks to Ross for telling me off-list the set of possible breakpoints
> for this problem).  I got the following stack trace:
> 
> #0  0x40d10053 in g_log () from /usr/lib/libglib-2.0.so.0
> #1  0x40bd1785 in g_type_register_static () from /usr/lib/libgobject-2.0.so.0
> #2  0x40b3f673 in Glib::custom_pointer_type_register () from /usr/lib/libglibmm-2.4.so.1
> #3  0x0805e3e0 in Glib::Value_Pointer<Pango::FontDescription, Pango::FontDescription*>::value_type_ ()
>     at typeinfo:88
> #4  0x0805e150 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
>     at value_custom.h:207
> #5  0x0805e22b in global constructors keyed to _ZN11FontBrowser21PresentationListStore12columnRecordE ()
>     at bind.h:1098
> #6  0x0805fa35 in __do_global_ctors_aux ()
> #7  0x08054891 in _init ()
> #8  0x0805f96b in __libc_csu_init ()
> #9  0x40e858b5 in __libc_start_main () from /lib/tls/libc.so.6
> #10 0x08056081 in _start () at ../sysdeps/i386/elf/start.S:102
> 
> which proves that the declaration I was suspecting is indeed the
> culprit.  So that is good.  However, it means that Glib::Value_Pointer
> is trying to use the type system before it has been initiated.  A strip
> down version of the class declaration is:
> 
> class PresentationListStore : public Gtk::ListStore {
>  public :
>   // . . . 
>   static class ColumnRecord : public Gtk::TreeModel::ColumnRecord {
>    public:
>     // . . .
>     Gtk::TreeModelColumn<Pango::FontDescription *> fontDescription ; // PROBLEM
>     ColumnRecord ( ) {
>       // . . .
>       add ( fontDescription ) ;
>     }
>   } columnRecord ;
>   // . . . 
> } ;
> 
> So the upshot of this is that it is not possible to use a
> Pango::FontDescription * as a model column if there is static instance
> of the column structure class.  Although I have only been using GTKmm
> for a couple of weeks or so, it strikes me as totally idiomatic that you
> would want a static instance of the column structure since it is
> effectively a singleton.  I guess the only way round this is to have to
> use a static method and dynamically allocate the object which is
> irritating but I guess is the only way round this issue of correct
> synchronization order?

It's an annoying aspect whenever you need to initialize a library, yes.
Feel free to suggest a patch to avoid this.

I suppose that you could initialize the type system from another of your
static objects. I think that libxml++ uses a similar technique to
initialize libxml. However, the order of initialization of static
objects is not easily predictable and varies between platforms.
 
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com