Re: Why isn't the constructor of Gtk::Application public?

[Chris Vine <vine35792468 gmail com>]

On Tue, 28 Sep 2021 22:26:46 +0200
<phosit 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.