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

51–60 of 66 posts

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

#51

Post by pansa2 »

waltersx wrote: post #45
netheril96 wrote: post #42

Earlier quoted context omitted.

Google writes a lot of C++ code, disables exceptions entirely, and it does not shy away from STL at all.

Then they don't care about applications being terminated in case of std::bad_alloc and similar. The crucial applications they use are written by others (like the Linux kernel). Also, having seen the output of several Googlers, I think their code quality is overrated.

> Then they don't care about applications being terminated in case of std::bad_alloc and similar.

No, they don't: https://youtu.be/NOCElcMcFik?t=2304

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

#52

Post by pjmlp »

jononor wrote: post #38
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++.…

I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains.

Until then C++ will do.

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

#53

Post by pjmlp »

ldng wrote: post #34
lrossi wrote: post #18

Earlier quoted context omitted.

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.

Here is the thing, GNU/Linux desktop developers aren't those who pays their bills, so they cater to the OS vendors and OEMs that actually pay them.

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

#54

Post by baybal2 »

ldng wrote: post #34
lrossi wrote: post #18

Earlier quoted context omitted.

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.

> They pushed 6 with regressions.

Gtk pushes every minor version with regressions.

Qt looks quite good in comparison.

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

#55

Post by rleigh »

pjmlp wrote: post #47
rleigh wrote: post #39

Earlier quoted context omitted.

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 anal…

I gateway drug to C++, was Turbo C++ 1.0 for MS-DOS, released in 1990 as per Wikipedia. I got my copy in 1992. Basically C++ARM as per language standard, on a 386SX running at 20 MHz, 2 MB but 640 KB was more than enough, right? :) Our high school teacher giving us C classes with Turbo C 2.0 also had it around, so as it were back in those days, I eventually got a copy. My gateway drug to programming until then were T…

Absolutely. Modern MCUs are phenomenal. More powerful than mid '90s top-end PCs. Add some external SDRAM and storage, and they have more and faster memory and storage as well. C++ is perfectly good. Better than all the nasty C macros in the vendor HALs, if you replace that nastiness with some type-safe enums and inline functions. There's plenty of capacity for running Python or Lua as embedded scripting languages even on smaller variants, both of which wrap C++ nicely. I'm fairly new to the embedded world, but so far it's been mostly a pleasure to write code for a variety of TI, ST and Nordic MCUs; some with C, some with C++.

I do see why people like C for embedded use; when it comes to hardware interaction you have complete visibility into all of the interactions with special registers. Looking through the disassembly when debugging is nice and straightforward. But C++ does this and more, so long as you don't go overboard with unnecessary complexity. It's fine with a bit of self-discipline, and all that extra bounds checking and such is of value.

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

#56

Post by jononor »

pjmlp wrote: post #52
jononor wrote: post #38

Earlier quoted context omitted.

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

I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains. Until then C++ will do.

Do you mean glib? It is in every server and desktop Linux distro, including those with commercial support from RedHat, Canonical and SUSE. For embedded Linux devices glib is included in Ubuntu Core from Canonical, as well as Wind River Linux from Intel. The GStreamer SDK includes glib and is supported by Fluendo and Collabora on Android, Windows and Mac.

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

#57

Post by pjmlp »

jononor wrote: post #56
pjmlp wrote: post #52

Earlier quoted context omitted.

I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains. Until then C++ will do.

Do you mean glib? It is in every server and desktop Linux distro, including those with commercial support from RedHat, Canonical and SUSE. For embedded Linux devices glib is included in Ubuntu Core from Canonical, as well as Wind River Linux from Intel. The GStreamer SDK includes glib and is supported by Fluendo and Collabora on Android, Windows and Mac.

Not at all, I mean Rust being available alongside C and C++ on OS SDKs, regardling tooling, IDE and libraries.

A checkbox on the installer, with first party support.

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

#58

Post by pjmlp »

rleigh wrote: post #55
pjmlp wrote: post #47

Earlier quoted context omitted.

I gateway drug to C++, was Turbo C++ 1.0 for MS-DOS, released in 1990 as per Wikipedia. I got my copy in 1992. Basically C++ARM as per language standard, on a 386SX running at 20 MHz, 2 MB but 640 KB was more than enough, right? :) Our high school teacher giving us C classes with Turbo C 2.0 also had it around, so as it were back in those days, I eventually got a copy. My gateway drug to programming until then were T…

Absolutely. Modern MCUs are phenomenal. More powerful than mid '90s top-end PCs. Add some external SDRAM and storage, and they have more and faster memory and storage as well. C++ is perfectly good. Better than all the nasty C macros in the vendor HALs, if you replace that nastiness with some type-safe enums and inline functions. There's plenty of capacity for running Python or Lua as embedded scripting languages eve…

In case you never seen this, enjoy Jason Turner's “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” talk. :)

https://www.youtube.com/watch?v=zBkNBP00wJE

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

#59

Post by loeg »

lrossi wrote: post #10
loeg wrote: post #4

Earlier quoted context omitted.

If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.

Qt is more like gtk rather than glib. Although it does come with a fantastic core library. But if you can move to C++, the standard library already offers great replacements for most glib features. Glib exists mostly because the C standard library is lacking in many aspects.

In the same way that using glib does not mean you are forced to use Gtk, you can use pieces of Qt without pulling in the GUI library. That's why I mentioned "non-GUI" explicitly.

https://en.wikipedia.org/wiki/Qt_(software)#Qt_modules

E.g., Core, Network, SQL do not require the GUI components.

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

#60

Post by loeg »

ognarb wrote: post #13
loeg wrote: post #4

Earlier quoted context omitted.

If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.

There is QtCore that is more similar in scope to glib and only containers, json and a few more useful stuff. It's a sort of alternate C++ standard library. Personally I wonder why people would choose today using C and Glib over C++ for system programming. I could understand why not Rust but for having to deal with glib in the past its so much of a pain.

As a mostly C and sometimes Rust programmer, I don't know why I'd ever reach for C++ instead of Rust these days. If I'm going to take on the mental complexity of these big languages, I'd rather have Rust's safety properties. (Not to mention, superior, portable, single-vendor standard library features — something C++ struggled with for a long time and probably still struggles with.)
Post reply on HN