3 ms·

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 he

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.

slovenlyrobot 7y ago
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)
- persistent 7y ago
  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.
  - icebraining 7y ago
    So is it a cornucopia of terrible ideas, or just a platform that has different goals and therefore tradeoffs?
- rumanator 7y ago
  > 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/ http://www.swig.org/
  - slovenlyrobot 7y ago
    My current favourite is pybind11. I wouldn't wish SWIG on my greatest enemy :)
thayne 7y ago
> 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.
the_why_of_y 7y ago
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.

slovenlyrobot 7y ago

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)

persistent 7y ago
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.
- icebraining 7y ago
  So is it a cornucopia of terrible ideas, or just a platform that has different goals and therefore tradeoffs?
rumanator 7y ago
> 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/ http://www.swig.org/
- slovenlyrobot 7y ago
  My current favourite is pybind11. I wouldn't wish SWIG on my greatest enemy :)

thayne 7y ago

> 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.

the_why_of_y 7y ago

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.