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

61–66 of 66 posts

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

#61

Post by pjmlp »

lrossi wrote: post #15
ognarb wrote: post #13

Earlier quoted context omitted.

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.

That’s exactly what I am thinking as well. Using C++ in moderation, without getting too crazy with classes, multiple inheritance, lambdas and other such things, works very well if you want to port a legacy C code base. For a new project, there are many choices: rust, go etc.

That is mostly how I use C++ nowadays, for writing native libraries to be called from Java/.NET, or GPGPU stuff.

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

#62

Post by qalmakka »

the_why_of_y wrote: post #50
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…

The main practical benefit of C is the simplicity and stability of its ABI. There are currently 8 different language bindings listed on LibVirt's website. It's not clear to me that this situation would improve by switching to a language as notoriously difficult to interop with as C++. https://libvirt.org/bindings.html

The point is, C++ supports the C ABI. You can write your entire application in C++ and expose only a C-style API with the stable ABI you wish. I've done it a million times and it's absolutely fine.

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

#63

Post by sovande »

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…

There is one significant thing that C has and C++ has not; a stable ABI. This is particularly important if you want to create a library that can be shared and used by everyone. You cannot do that with C++ without a lot of caveats. Google, for instance, forbid creating libraries in C++ for good reasons. Creating a C++ library with a C ABI sounds stupid. I.e. if the library’s functions and types can be presented as simple C, you have already folded down to C and C++ is just an implementation detail and you will probably also have to static link libstdc++. That’s no longer a small, simple library anymore. The stable ABI makes C also famously easy to include and inter opt with other languages and frameworks. Swift for example can easily utilize C libraries and code but cannot inter opt with C++ (yet, apparently it’s wip)

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

#64

Post by ldng »

baybal2 wrote: post #54
ldng wrote: post #34

Earlier quoted context omitted.

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.

Well if you don't count missing modules as regression, sure ...

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

#65

Post by ldng »

pjmlp wrote: post #53
ldng wrote: post #34

Earlier quoted context omitted.

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.

And I fine with that. But then drop the multi-platform bullet point from the marketing brochure. It becomes a lie at some point.

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

#66

Post by samus »

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

C++ seems difficult to embed because there is no standard way to expose features that don't map well to the C calling convention. Just use `extern "C"` if you want a C API. For everything else you'd have to commit to an application binary interface first, such as GObject, COM or the CLR. You need these to define calling conventions and semantics (such as initialization, exceptions, memory and resource management) well enough that other languages can bind to them.
Post reply on HN