Hacker News Reader

Comment by Dreami | Hacker News Reader

Could you elaborate a bit? I don't know much of their code base (but I've used it as a user) and I'm curious as to what is done wrong.

View on HN

GTK and GIMP both suffer from the original decision by people who don't understand C++ to reinvent it in bare C except very poorly. It's what you get if you heard a rumor that vtables are bad somehow but don't realize that an array of function pointers is worse in every way.

Having worked with GObject extensively, including through PyGObject, I can say the experience is infinitely better than trying to make C++ interoperate with e.g. Python.

(This coming from someone writing C++ since 2002)

That makes sense since the implementation of things in GObject is basically the same as the internal architecture of Python. Since it's all just named properties and function pointers there's no chance that the compiler will rearrange it and break introspection. On the other hand there's also no chance that the compiler can optimize a GObject program, so you've traded good performance for an easier-to-use FFI for Python which might not be the trade I would have made. They've also traded away core developer productivity in order to make foreign language developers more productive, again a tradeoff I might not have made.

So is it a cornucopia of terrible ideas, or just a platform that has different goals and therefore tradeoffs?

> Having worked with GObject extensively, including through PyGObject, I can say the experience is infinitely better than trying to make C++ interoperate with e.g. Python.

Have you tried SWIG?

http://www.swig.org/

My current favourite is pybind11. I wouldn't wish SWIG on my greatest enemy :)

> It's what you get if you heard a rumor that vtables are bad somehow but don't realize that an array of function pointers is worse in every way.

No, it's what you get when you need an object system that works across FFI boundaries.

GObject is a ref-counted object system that is designed to make interop with all sorts of languages possible across FFI boundaries, including those with runtimes that include tracing GCs; such a thing is not built into C++.

If the GIMP authors would have used C++ in 1995 they would be stuck with a legacy codebase now that would be ridiculed because it's not "modern C++" - a term that has designated about 3 different programming styles during that time.

Even the Qt developers found that 1995 C++ was insufficient for a UI toolkit and augmented it with a custom "moc" pre-compiler and build tools.

Reply on news.ycombinator.com