I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and reuse allocations.

It’s also a major security risk, since it nullifies hardening measures from the standard library, as we have seen with openssl/heartbleed recently.

https://developer.gnome.org/glib/stable/glib-running.html#G_...

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) */

Except that this is what you actually end up doing when using any kind of nested glib containers. Elements are always void*, so you have to cast them correctly. So for non-trivial applications, it’s very easy to make mistakes, since you lose the type checking support of the compiler.

C is already a tricky language. Removing the type checker makes it even worse.

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 willingness to throw out their hacky attempts to replicate new c++, and standard lib functionality.

The Glib+Gtk world, unlike Qt, still lives in ANSI C, and C99 era, and refuses to concede on reinventing functionality of modern standard libraries, language features, and compilers.

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 read. You can tell that their team is very experienced. I used to read their blog as well, they had a lot of good articles.

I really hope that they can continue to survive financially. Selling a mostly open source library is not very profitable.

Qt is undoubtedly interesting but really have steering issues.

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/

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

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

I immediately thought g_malloc but it seems to call directly to libc: https://github.com/GNOME/glib/blob/master/glib/gmem.c

The only real universal sore spot IME has been arrays and vectors. But nobody seems to pitch glib as a way to get a fast and ergonomic FIFO buffer. There are many other areas without simple, go-to solutions, but then that's the nature of C programming. Most of the C programmers I interact with are multi-language programmers, as opposed to many C++, Java, etc engineers who lean toward single-language, monolithic approaches.

I can understand using glib for GUI applications, considering it's already a requirement for Gtk, and because of the OOP emphasis in GUI programming. But IMNSHO, in most other areas the right reasons for selecting C as your implementation language are mutually exclusive with the need for cookie-cutter, void-pointer heavy data structure implementations a la glib.

EDIT: Removed outdated discussion of systemd + glib.

No, you are wrong. Ideas like that are a big reason that apps get slower despite hardware getting faster.

For example, I've done some work with audio or video. Nobody working on that goes straight to malloc on every packet or frame. It'd just be asking for pain.

But a general purpose allocator doing its own free-list on the assumption that libc is going to suck? I think that's outdated. If you do want to support it, I think it's better to allow the caller to replace the allocator through a function pointer, rather than just do it by default in a library.

I think libstc++ on the other hand does or did have such a cache as an always-on thing though. So not unheard of.

Yup [0].

There's even other complete libraries like tcmalloc [1] and jemalloc [2].

[0] https://stackoverflow.com/a/262481/1111557

[1] https://github.com/google/tcmalloc

[2] https://github.com/jemalloc/jemalloc

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.

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.

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 Turbo Pascal 6.0 and TASM, and C++ was in the same ballpark of features and culture for safer systems programming.

Never had any issues using it in such kind of PCs, including with my own bounds checked string and array classes, hardware that most modern MCUs can easily outperform.

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.

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

Until then C++ will do.

A checkbox on the installer, with first party support.

Then FOSS happened with its manifesto to use C for portability, war on KDE due to licensing gave raise to Gtk and related eco-system, and here we are.

Thankfully I learned C++ on MS-DOS and became enlighted, even with its 640 KB limit it was already so much better than the primitive C, in regards to type safety, generic code and yes RAII was already a thing.

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

If you write C-style C++, which parts of libstdc++ can you safely use without exceptions?

Almost all of it, as long as you're happy to abort on memory allocation failure - which, according to the article, libvirt is now willing to do.

In fact for me, that's one of the main questions to ask when deciding between C and C++ for a project. Is it OK to abort on allocation failure? If so, use C++ (without using exceptions). If not, use C.

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.

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

   auto ptr = new (std::nothrow) ......
   if (ptr != nullptr) {
       //........
   }

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?

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

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/

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.

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.

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.