Commit Graph

5 Commits

Author SHA1 Message Date
Matthias Clasen
03db2690e2 testsuite: Reduce use of g_assert
Stop using g_assert() in the gdk tests.
2021-04-12 08:18:00 -04:00
Matthias Clasen
131a61c51b testsuite: Fix a leak
asan pointed out that the array tests leak.
2021-01-22 11:50:04 -05:00
Benjamin Otte
96e1b85c2c gdkarray: Add a "stolen" boolean to splice()
If set to TRUE, does not call the free func for the removed items.

This can be used to move items between arrays without having to do the
refcounting dance.
2020-12-24 06:38:45 +01:00
Benjamin Otte
a4cd974912 array: Add null-termination 2020-07-16 18:09:57 +02:00
Benjamin Otte
8bf8ac5076 Add GdkArray
This is a scary idea where you #define a bunch of preprocessor values
and then #include "gdkarrayimpl.c" and end up with a dynamic array for
that data type.

See https://en.wikipedia.org/wiki/X_Macro for what's going on.

What are the advantages over using GArray or GPtrArray?

 * It's typesafe
   Because it works like C++ templates, we can use the actual type of
   the object instead of having to use gpointer.

 * It's one less indirection
   instead of 2 indirections via self->array->data, this array is
   embedded, so self->array is the actual data, and just one indirection
   away. This is pretty irrelevant in general, but can be very noticable
   in tight loops.

 * It's all inline
   Because the whole API is defined as static inline functions, the
   compiler has full access to everything and can (and does) optimize
   out unnecessary calls, thereby speeding up some operations quite
   significantly, when full optimizations are enabled.

 * It has more features
   In particular preallocation allows for avoiding malloc() calls, which
   can again speed up tight loops a lot.
   But there's also splice(), which is very useful when used with
   listmodels.
2020-07-16 18:09:57 +02:00