[marktangotango]

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

[saurik]

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.

[JNRowe]

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/

[stretchcat]

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.

[h_anna_h]

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

[tyingq]

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

[loeg]

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

[ognarb]

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.

[loeg]

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

[lrossi]

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.

[pjmlp]

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

[PaulDavisThe1st]

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

[lrossi]

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.

[PaulDavisThe1st]

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.

[loeg]

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.