GHashTable usage and memory leak issues

[Igor_Morgado]

Hello,

I have written a small snippet to test GHashTable. It stores a bunch of struct objects * inside a struct Manager. Seems very convolute, but my manager has much more data fields than a single GHashTable (here I have simplified Manager ).

The code is creating/deleting objects from manager very easily as the snippet below

struct manager * mgr = manager_init();
char *oid = manager_new_object(mgr);
manager_new_object(mgr);
manager_new_object(mgr);
manager_print(mgr);
manager_del_object(mgr, oid);
manager_destroy(mgr, true);

I have some questions about the code: hashtesting.c.

1. Valgrind complains about “still reachable” memory in object_init() and object_print(). I was not able to find out what I’m leaving behind.

2. Two wrapper functions were created to be used as arguments to g_hash_table_foreach, is that a good practice?

3. I prefer not use GLib types and stick with C99 standards. But I’m not able to return bool from object_equal since the prototype to GEqualFunc expects gboolean is typedef'd as gint that is the same a int. Is there anyway to use C99’s bool in this case? How to handle it?

4. Is there any way to store GUuid using the 128bit format instead the 37bytes? And converting it to string only when needed? This way I think will be faster to transverse the memory while checking multiple objects in sequence.

5. Of course, any additional expert advices are always very welcome and happly expected.

Best regards.

[zbrown (Zander Brown)]

First things first: Your reinventing GType, why?

1. Your using free() not g_free () on a value from g_malloc which != malloc. This may not be the cause of your valgrind issues but it is an error
2. Do you mean _manager_object_unref? You should have set a destroy, see g_hash_table_new_full
3. As a general rule there is no reason to use the likes of gint over int, they are just typedefs, but gboolean is not bool - you cannot decide not to follow API for stylistic reasons

#include <glib.h>
#include <stdbool.h>

int
main (int argc, char **argv)
{
  g_print ("bool %i gboolean %i\n", sizeof (bool), sizeof (gboolean));

  return 0;
}

bool 1 gboolean 4

4. You can intern the strings, then it’s direct pointer comparison which is even better than comparing 128bit numbers (unless your on a 128bit system guess)
5. Me? Expert?

[Igor_Morgado]

@zbrown

First things first: Your reinventing GType, why?

I don’t know about it. I really want to learn more about GObjects but haven’t found good learning materials except this amazing video and the official documentation API (that isn’t much friendly).

@zbrown

Do you mean _manager_object_unref ? You should have set a destroy, see g_hash_table_new_full

Yes. I have some personal notes here to use g_hash_table_new_full instead doing my own unrefs. I think I will change the code a little to handle this.

@zbrown

gboolean is not bool

I know that, but some time ago, I have spoken with someone (that I can’t recall) that said isn’t a issue to use _Bool in place of gboolean. They are different (indeed) but they “converge” to same data. He also said that inside Glib they had to use !! to sanitize the values received in gboolean.

(not a rant) But after 21 years I think (IMHO) that is safe enough to move to C99 standards.

[zbrown (Zander Brown)]

I guess you’ve already seen “How to define and implement a new GObject” then, must admit we aren’t great at explaining these things. I think most of us figured it out by trial and error looking at existing objects.

Sometimes I even read the code generated by valac

It’s okay to mix in a lot of places, just like different sizes ints, but parameter/return types of course are another matter

We do actually require C99 the problem is we’ve not really broken ABI since GLib 2.0 in 2002 and GLib 3.0 is unlikely to happen anytime soon (if at all) so we’re stuck 20 years ago - if we were starting today we probably would have _Bool not gboolean

[Igor_Morgado]

@zbrown

I guess you’ve already seen “How to define and implement a new GObject”

Yes. That isn’t helpful at all. Unfortunately.

IMHO I think GLib/Gnome need a good GObject tutorial (instead expect new adopters learn it by trial and error). There are some materials online that try to explain GObject , but the content is so awful and with so many errors that looks like a disservice. I’m far from an expert, but I know when some is talking bullshit and just had luck making something work and think is himself a expert and put some bad videos online.

Doing a small but official videos/documentation for newcomers is a huge improvement in how ppl will use and build tools with GLib, but I think I’m digressing from my own original topic (and I had already complained about these issues here), but in reality, I’m evolving in GLib, but it always comes down to bad documentation (or probably I’m just aretard (besides an applied math PhD)).

Thank you for your help, regards the original question, helped a lot.

[zbrown (Zander Brown)]

Yh unfortnuatly there are lot of tutorials out there which are either horribly outdated for modern best practices or where just always wrong

This is somewhat a known bug, and there are efforts to improve the situation: https://www.gnome.org/challenge/ https://www.gnome.org/news/2020/05/gnome-season-of-docs-2020/

But yes, we’re getting somewhat off topic now

PS: I gave up on maths after scraping an E grade AS, on the second attempt, so I’m the dumb one here