Use something other than glib
Opened this issue · 13 comments
Reasons: https://suckless.org/sucks/
List of alternatives:
https://suckless.org/sucks/ lists three "alternatives" to glib, each one less popular than cito, and neither seems to implement a resizable array or regular expressions.
From your lists of alternatives, I only heard about APR before.
Because traditional alternatives to glib are too limited people come up with many newer solutions, especially embedded people as glib is clearly not suitable for embedded. Please have a look at TBOX.
p/s: I don't suggest you to choose TBOX, it only served as an example to show how capable modern alternatives to glib are.
TBOX looks promising. One problem I see is no SortedDictionary / std::map / GTree equivalent.
You could try submitting an issue and asking the developer to add it:
You should have a look at other solutions too. If you only need data structures then there are many other alternatives (on both the data structures section and frameworks section of the awesome-c collection).
@pfusik Should this issue be closed as not planned?
Yes, I see no reason to provide an alternative to glib in near future.
TBOX looks promising. One problem I see is no
SortedDictionary/std::map/GTreeequivalent.
@pfusik TBOX does have std::map equivalent:
https://github.com/tboox/tbox/blob/master/src/tbox/container/hash_map.h
The developer of TBOX has commented: tboox/tbox#239 (comment)
Yes, I see no reason to provide an alternative to
glibin near future.
I think this is an legitimate concern. Please reopen this issue. You don't have to remove support for GLib. Both GLib and TBOX should be available as backends when transpiling to C. Perhaps you should add a new switch for that.
List of alternatives:
There are many libraries freely available for you to pick up. You don't have to choose TBOX.
Why evaluate alternatives? What's wrong with glib?
Why evaluate alternatives? What's wrong with glib?
glib aborts in out-of-memory situations. Please read https://suckless.org/sucks/ again.
glib aborts in out-of-memory situations.
Like most of all software. If your program uses 10 GB of RAM, how do you think it can work when there's no 10 GB of RAM available?
glib aborts in out-of-memory situations.
Like most of all software. If your program uses 10 GB of RAM, how do you think it can work when there's no 10 GB of RAM available?
Desktop software, to be clear. The situation is different on the server. After multiple attempts to allocate memory but all failed, it's OK for you to abort. But abort on the first failed attempt to allocate memory? This is unreasonable.
Imagine you are on a build server. You will see multiple gcc processes being spawned. They will very soon eat up all of the available memory. Do you think they should be aborted? Nope. They are very short-lived processes. They will terminate very soon. This means the gcc processes will just keep going until there are some gcc processes terminated so they can allocate memory. If the gcc developers think like you, no parallel build system could work since nothing could be built because gcc will terminate itself on the first failed attempt to allocate memory!