@akaster hey. So back when I was building a gtkmm project with CMake, I used something much simpler, just looking up gtkmm through pkg_check_modules and linking to the imported target. But, I wasn't trying to do all of this "build a version from source if not new enough". Which I understand the appeal of, and it's nice when Meson does that for subprojects, without you having to write tons of logic on your side to get it.

But also, I no longer have to use gtkmm  peel is now public, and it comes with some CMake integration (which I've even written the docs for: https://bugaevc.pages.gitlab.gnome.org/peel/using-peel-with-cmake.html). Which is imperfect by the way, and improvements welcome.

@bugaevc following up on this old post, why does peel not call object constructors?

That feels ... c++-hostile, at the very least. I saw in the README/docs and some issues that the goal of peel is to be as faithful to GTK as possible, but ... maybe I'm missing something.

Is it truly not possible to

```
auto* p = g_object_new(...)
new (p) MyClass; // call c++-generated constructor
static_cast<MyClass*>(p)->init();
```
?

The documentation I saw that suggested doing

```
void
MyClass::init()
{
new (&m_vec) std::vector<int>{};

...
}
```

feels like a bridge too far in being C-like.

I would expect a C++ library to either call my class's constructors, or enforce that all 'classes' are trivially constructible, to avoid foot-guns/awkward situations like that.

@akaster hey, so, the overall reason is that GObject construction and C++ construction work differently enough that it's not worth to try and make them work in tandem. I have thought about this a lot, because it would be really nice if it just worked (like it does with destruction), but ultimately decided that's not worth it. That is true of many many "core" aspects of peel (like this one): the design has been thought over excessively, even though you might not immediately like the result.

If you want some more details: consider that the C++ constructor expects to initialize all the memory the instance occupies, including that of the parent class subobject, whereas in reality the parent class data will be initialized by the actual parent type's initializer, and C++ has to keep its hands off that memory. Also that GTypeInstance initialization happens in turns, from the root type (GObject) down to the concrete type, and at each turn the object's dynamic type is set to that type being initialized — so e.g. if a vfunc gets called at this point, it'd be that class'es vfunc implementation (C++ also does a similar thing with its virtual classes); and GTK makes serious use of this (Gtk.Widget.init_template() works with the current type of the object) — you can't really make this work if the initialization is driven from the C++ side.

We also cannot require that the class is trivially constructible, exactly because it might not be, you may want to do some initialization. Using e.g. a RefPtr (which defaults to nullptr, and doesn't have to be explicitly initialized in fields of GObject) would instantly kill trivial constructibility too; but this is something we want to encourage, and so make simple, not prohibitively complicated. Also we delete the default constructor for classes, so people don't accidentally try to stack allocate them; trivial constructibility requirement wouldn't work with that either.

In my experience using peel, it ends up not actually being much trouble, especially if you mostly use peel's own types which come with a promise that zero-initialization is fine. For the occasional STL type, yes, you have to call the constructor explicitly. This became even more true once I stopped using std::string in favor of peel::String; now it's mostly vectors that remain.

So are/were you considering peel for some project? What are you trying to do?