On Tue, 28 Sep 2021 18:26:51 +0100
Rob Pearce <r...@flitspace.org.uk> wrote:
> On 28/09/2021 15:07, pho...@autistici.org wrote:
> > If the constructor would be public we and the compiler wouldn't have to
> > deal with smart pointers:
> >
> > Gtk::Application app("org.example");
> > return app.make_window_and_run<MyWindow>(argc, argv);
> >
> > The Gtk::Application::create function just passes the argument to the
> > constructor and stores the Gtk::Application in a Glib::RefPtr. Is there
> > a reason why the constructor isn't public?
>
> At a guess... precisely to prevent you doing what you suggest!
>
> Statically allocated complex class instances are seriously problematic
> in C++ because the order of initialisation and instantiation of "static"
> objects is very poorly defined. There were many places in GTKmm 2.4
> where objects that could be instantiated statically would simply break.
> The correct approach was always to dynamically generate a singleton and
> use that, thus providing a guaranteed order of creation.
I doubt anyone is going to attempt to construct a Gtk::Application
object statically, and the fact that such objects are held by
Glib::RefPtr doesn't stop you doing so anyway, in the sense that you
could attempt to call Gtk::Application::create() before main is
entered in order to initialize a RefPtr in namespace scope. That
almost certainly wouldn't work though because you can't initialize GTK
statically.
I suspect the real reason is that GtkApplication derives from
GApplication which derives from GObject rather than GInitiallyUnowned.
Such objects are conventionally held by Glib::RefPtr in the gtkmm
wrapper. Types which derive from GInitiallyUnowned, such as widgets,
conventionally do not. It didn't necessarily need to be that way (that
is an old debate) but that's the way it is. Consistency is good.
Chris
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
