Hacker News Reader

Comment by marktangotango | Hacker News Reader

> These problems are common to many applications / libraries that are written in C and thus there are a number of libraries that attempt to provide a high level “standard library”. The GLib library is one such effort from the GNOME project developers that has long been appealing.

I've been a fan of glib for some time, other than glib and apache libapr, what other "high level standard libraries" for C should I know about?

View on HN

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...

> Netscape Portable Runtime (NSPR) provides a platform-neutral API for system level and libc-like functions. The API is used in the Mozilla clients, many of Red Hat's and Oracle's server applications, and other software offerings.

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 configs are lua & lgi, extended with gexiv2 also via gobject-introspection.

³ https://mpv.io/

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.

Qlibc: http://wolkykim.github.io/qlibc/

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

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.

Even the Qt folks accepted, though, that for run/event-loop integration between glib and Qt code, it was Qt that provided a way to use the glib event loop not vice versa (because Qt doesn't offer a sufficiently hook-able event loop abstraction).

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.

That's only partially true. You'd really something like boost to cover a lot of things that glib provides for C. glib covers many, many things that are outside of the scope of both the C++ and C standard libraries.

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.

Reply on news.ycombinator.com