Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libvirt: Adoption of GLib library to replace GNULIB and home grown code

berrange.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#31

Post by the_why_of_y »

baybal2 wrote: post #16
lrossi wrote: post #9

Earlier quoted context omitted.

I am aware of that environment variable. The problem is that I think almost nobody is using it, so it could come with a risk of introducing more bugs. By the way, the example shown in the documentation page that you link to seems ridiculous: void *slist = g_slist_alloc (); /* void* gives up type-safety */ g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */ This bug should actually be caught durin…

You seem to know a lot about Glib. What did you do with it? I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs. For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well! Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and w…

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt.

This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effort.

https://gi.readthedocs.io/en/latest/

It also means that the implementation behind the ABI can be replaced with a different language such as Rust, as has already been done with librsvg. On the other hand, Qt will forever be stuck with legacy C++ language, which appears designed to be nigh impossible to interop with.

And if you have a requirement to use C++, there is the gtkmm binding too, which doesn't require a separate language extension such as Qt's MOC to use.

https://www.gtk.org/docs/language-bindings/cpp/

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#32

Post by qalmakka »

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere.

Glib2 is one excellent example of how people have been shunning C++ due to its complexity, while on the other hand implementing overly complex libraries to mitigate the fact it's too barebones, which is oxymoronic to me. Either you say C is better because its simplicity and you keep stuff simple, or you are just being a zealot for the sake of it.

Basically everything I can put my hands on supports C++, I've been running massive applications on embedded microcontrollers and it works as fine as C. If you don't like some features, just write C-style C++, use the C ABI and #include all the containers you need.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#33

Post by baybal2 »

the_why_of_y wrote: post #31
baybal2 wrote: post #16

Earlier quoted context omitted.

You seem to know a lot about Glib. What did you do with it? I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs. For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well! Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and w…

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt. This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effo…

Well, I mean they could've moved up to more recent standards well within the C world.

As of now, Glib doesn't even utilize much of C99.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#34

Post by ldng »

lrossi wrote: post #18
baybal2 wrote: post #16

Earlier quoted context omitted.

You seem to know a lot about Glib. What did you do with it? I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs. For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well! Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and w…

I worked on some Linux apps in another life. I switched to Qt at some point. It was a breath of fresh air! Qt is very reliable and well documented. One can be very productive with it. I think a lot of people have a bad opinion about it as they confuse it with KDE. While KDE does use Qt, the two projects are otherwise independent. I’ve also looked inside the Qt code base a few times. It’s very tidy and quite easy to r…

The problem with Qt is The Company. They have a tendency to cater to their exclusive needs and not bothering much with Linux. A bit like Mozilla. Yet they're claiming to be fully cross-platform. They pushed 6 with regressions.

Qt is undoubtedly interesting but really have steering issues.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#36

Post by h_anna_h »

stretchcat wrote: post #22
JNRowe wrote: post #7

Earlier quoted context omitted.

I can't offer extra recommendations, but just wanted to offer full agreement. GLib is the awesome standard library I get to use everywhere thanks to gobject-introspection. From work projects in Vala, window manager¹, image viewer², video player³. It is especially useful with lua configurable projects, given the sparsity of the language itself. ¹ https://awesomewm.org/ ² https://github.com/muennich/sxiv - my user conf…

Incidentally, mpv is extensible enough to replicate sxiv's features with the right configuration and scripts. I like to think of mpv as the emacs of multimedia.

mpv eats a lot of memory even when you use it to just view images.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#37

Post by h_anna_h »

lrossi wrote: post #9
the_why_of_y wrote: post #8

Earlier quoted context omitted.

Did you try to disable the slab allocator? https://developer.gnome.org/glib/stable/glib-running.html#G_...

I am aware of that environment variable. The problem is that I think almost nobody is using it, so it could come with a risk of introducing more bugs. By the way, the example shown in the documentation page that you link to seems ridiculous: void *slist = g_slist_alloc (); /* void* gives up type-safety */ g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */ This bug should actually be caught durin…

> g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */

Catching this error at runtime would be extremely trivial. Just add a magic number on top of the GSList and GList structs.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#38

Post by jononor »

qalmakka wrote: post #32

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, w…

Agreed in general on using C++ over C, or C-style C++ in constrained environments. One thing that is nice about using C though is that it is quite easy (compared to C++) to expose to other languages. Glib, and most libraries built on it like GTK, GStreamer, etc can be used in languages such as Python, JavaScript et.c.. And a lot of development of applications and tools has been moving to such languages over say C++. So C is still useful for low-level libraries, due to being the lowest common denominator. Though arguably one could today write the library core in a better language like Rust maybe, and expose a C API/ABI from that. Rsvg is growing into an example of that.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#39

Post by rleigh »

qalmakka wrote: post #32

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, w…

Absolutely. It makes perfect sense, and in an ideal world this would be the direction which would benefit many, if not most, projects using C and/or GLib2. Unfortunately, there are far too many people who are wedded to the philosophy that C is perfect for every task, and C++ is the devil. Despite the fact that GLib/GObject are more complex than C++, more error-prone than C++, slower than C++ and make static code analysis impossible (due to all of the unsafe typecasting).

A few years ago now, I ported a C GLib/GObject-based application to C++. In removing all of the unnecessary typecasts I found a couple of minor (but real) bugs which were previously hidden from the compiler. Simple use of real classes, along with basic containers like vector and map, was the vast majority of the C++ usage in the whole application. It benefitted greatly in becoming smaller, simpler, easier to read, easier to maintain, and having the compiler able to typecheck everything.

Like yourself, I've also used C++ on MCUs. Some vendors even provide an "Embedded C++" C++ subset you can use, which is "safe" for safety-critical real-time code. Works fine. A lot of C embedded projects would benefit from the extra safety it provides. So long as you don't go overboard with the features; stick to a simple and easy to understand subset.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#40

Post by Asooka »

the_why_of_y wrote: post #31
baybal2 wrote: post #16

Earlier quoted context omitted.

You seem to know a lot about Glib. What did you do with it? I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs. For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well! Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and w…

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt. This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effo…

Qt can trivially offer a C ABI if they want. Glib can't be type safe no matter how hard they try. People don't seem to have any trouble making Qt bindings for languages like Go, Python, Java, all of which you could say strongly prefer interop with C. Part of the reason is that Qt is written in a way that avoids use of more exotic features and templates for most things. MOC could be replaced by template magic nowadays, but I don't see any value in doing so - you will just make compilation slower and bindings with other languages harder.
Post reply on HN