On Tue, 28 Sep 2021 22:26:46 +0200 <pho...@autistici.org> wrote: > So because objects of a classes inheriting from GObject are held by > Glib::RefPtr's Gtk::Application's are also held in Glib::RefPtr's? > > I think smart pointer should only be used if they are needed. Probably > this is only my philosophy and if you discussed it already i will not > insist of it being public.:)
(1) I haven't discussed it, as far as I am aware, or if I have it was in the mists of time. I recall that the matter has been discussed. The origins of the gtkmm wrappings go back nearly 20 years. Things are as they are, and in real life consistency is important. (2) Your posting is public, which is fine. There is nothing inappropriate in it. > btw. now that Glib::RefPtr is a std::shared_ptr you could use > std::make_shared(). > (also my philosophy) That wouldn't work. GObject and cognates are the materialization of an object system for C, and GObject objects are constructed by their C constructors. glibmm makes a brave attempt at wrapping that within the C++ object system, but that is all it does. On that note, the conversion of Glib::RefPtr to std::shared_ptr seems silly to me: C++ intrusive pointers interfacing with GObject reference counting are fine. But I have not used gtkmm for a number of years (and C++ does not have the buzz it used to) so it is possible I am missing something new about glibmm. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
