GNOME Bugzilla – Bug 443586
Introduction to TreeView is misleading
Last modified: 2007-11-05 08:57:31 UTC
About 2/3 of the way down the first page of chapter 8 of the GTKmm book, where the TreeModel/TreeView scheme is discussed, there is a code extract of how to declare a TreeModelColumnRecord. This example looks as if it intends that a static instance of the derived class should be created. I am told that this is not the intention, and that this reference instance should be a member of the TreeModel-derived class. Also, the reference documentation for Gtk::TreeModel::ColumnRecord explicitly states: Thus it's absolutely legal to use a statically allocated TreeModel::ColumnRecord (as long as you make sure it's instantiated after Gtk::Main), even when creating multiple models from it. Given the difficulty of ensuring order of instantiation of static objects, this wording could possibly also do with tweaking.
> About 2/3 of the way down the first page of chapter 8 of the GTKmm book, where > the TreeModel/TreeView scheme is discussed, there is a code extract of how to > declare a TreeModelColumnRecord. This example looks as if it intends that a > static instance of the derived class should be created. Exactly what part of the text do you mean? I can't see anything that explicitly suggests that it should be static. > Also, the reference documentation for Gtk::TreeModel::ColumnRecord explicitly states I have changed the text to: " * Thus you may use a statically allocated * TreeModel::ColumnRecord (as long as you make sure it's instantiated after * Gtk::Main), even when creating multiple models from it. However, it is very difficult to * specify the sequence of allocation of static objects, so this should probably be avoided. "
> Exactly what part of the text do you mean? I can't see anything that explicitly > suggests that it should be static. Did I say explicitly? The example code extract shows a class declaration. In the absence of any indication to the contrary, this would normally be expected to live at the top level. Thus the instantiation that follows would be a static one. That's certainly how I read it. If there is a good reason why a class should be declared only within a restricted scope (particularly within the scope of another class declaration), I would think it worth mentioning that. Especially if the consequences of doing it wrong can be obscure or not show up until months later.
I have added another warning in the tutorial in that section: " Note that the instance (such as m_Columns here) should usually not be static, because it often needs to be instantiated after glibmm has been instantiated. "