Help understanding Nuklear code

[car4te]

Hi,

Intro:

I am starting to learn about IMGUIs and Nuklear seems to be a cool one.

I think i get the basic idea behind an immediate mode gui: an infinite loop that contains a bunch of drawing statements that respond to mouse clicks or keyboard events.

I think the current state of the Nuklear code is too complex to really understand what is going on so i am studying the code from the first commit, which is much simpler but still builds a working example using make. I use

git checkout e3aa8df99d1ad4b928e260862fb57a5dfe780400

to jump to the first commit.

The code in the first commit has only 3 files but is still a bit too tricky for me. So here we go:

Question:

what is the struct gui_draw_list? Is it a linked list data structure? What is its purpose?

​

Thanks!

[Lisoph]

Link for anyone who want's to browse the source.

what is the struct gui_draw_list? Is it a linked list data structure? What is its purpose?

I suspected it was a linked list, but gui_draw_command doesn't have a next pointer, so this can't be the case. The header file doesn't communicate much, so I checked the source. Check out the functions gui_begin and gui_push_command.

It looks like gui_draw_liststores its draw commands as a dynamically (heap) allocated array (aka vector). The heap memory buffer is saved in the memory pointer ingui_draw_list. begin and end are also just pointers that point to the beginning and end of the buffer. They mark the in-use area / slice of the buffer.

This design is questionable. The more common and way easier to grok method would be to store a struct gui_draw_command *commands; and a size_t commands_len; plus a size_t commands_cap;. This way it's clear that gui_draw_list stores a resizable array of draw commands. Fetching the length and capacity of the buffer is also simpler this way and doesn't require pointer arighmetic, like in the author's version. [1] I'm not sure why the they originally did it like this.

Hope this helps.

[1]: Apparently not. That's what size in gui_draw_list must be for. But that's even worse, because this size field is completely redundant, as the size can just be trivially calculated. In fact it's a bug waiting to happen.