summaryrefslogtreecommitdiff
path: root/gdk/gdkarrayimpl.c
Commit message (Collapse)AuthorAgeFilesLines
* gdk/gdkarrayimpl.c: Fix build on Visual StudioChun-wei Fan2020-07-241-2/+2
| | | | | It seems like initializing something to an empty array using `{}` is a GCCism, so just stuff a 0 within the braces to accomplish the same thing.
* array: Add a bunch of new featuresBenjamin Otte2020-07-161-16/+55
| | | | | | | | | | * GDK_ARRAY_BY_VALUE #define this to get GArray-like behavior * gdk_array_splice (v, 0, 0, NULL, 25) Adding items but passing NULL as the items will zero() them. * gdk_array_set_size() A nicer way to call gdk_array_splice() * constify getters
* array: Add null-terminationBenjamin Otte2020-07-161-7/+32
|
* Add GdkArrayBenjamin Otte2020-07-161-0/+219
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.