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-02 15:23:09 +00:00
|
|
|
/*
|
|
|
|
* Copyright © 2020 Benjamin Otte
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* Authors: Benjamin Otte <otte@gnome.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <gtk/gtk.h>
|
|
|
|
|
|
|
|
#define GDK_ARRAY_NO_UNDEF
|
|
|
|
|
|
|
|
#include "../../gdk/gdkarrayimpl.c"
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_array(test_simple) (void)
|
|
|
|
{
|
|
|
|
GdkArray v;
|
|
|
|
gsize i;
|
|
|
|
|
|
|
|
gdk_array(init) (&v);
|
|
|
|
|
|
|
|
for (i = 0; i < 1000; i++)
|
|
|
|
{
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), ==, i);
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), <=, gdk_array(get_capacity) (&v));
|
|
|
|
gdk_array(append) (&v, i);
|
2020-07-02 21:32:04 +00:00
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
|
|
|
g_assert_cmpint (*gdk_array(index) (&v, gdk_array(get_size) (&v)), ==, 0);
|
|
|
|
#endif
|
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-02 15:23:09 +00:00
|
|
|
}
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), ==, i);
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), <=, gdk_array(get_capacity) (&v));
|
|
|
|
|
|
|
|
for (i = 0; i < 1000; i++)
|
|
|
|
{
|
|
|
|
g_assert_cmpint (gdk_array(get) (&v, i), ==, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
gdk_array(clear) (&v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_array(test_splice) (void)
|
|
|
|
{
|
|
|
|
GdkArray v;
|
|
|
|
gsize i, j, sum;
|
|
|
|
gsize pos, add, remove;
|
|
|
|
int additions[4] = { 0, 1, 2, 3 };
|
|
|
|
|
|
|
|
gdk_array(init) (&v);
|
|
|
|
sum = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < 1000; i++)
|
|
|
|
{
|
|
|
|
gsize old_size = gdk_array(get_size) (&v);
|
|
|
|
|
|
|
|
pos = g_random_int_range (0, old_size + 1);
|
|
|
|
g_assert (pos <= old_size);
|
|
|
|
remove = g_random_int_range (0, 4);
|
|
|
|
remove = MIN (remove, old_size - pos);
|
|
|
|
add = g_random_int_range (0, 4);
|
|
|
|
|
|
|
|
for (j = 0; j < remove; j++)
|
|
|
|
sum -= gdk_array(get) (&v, pos + j);
|
|
|
|
for (j = 0; j < add; j++)
|
|
|
|
sum += ++additions[j];
|
|
|
|
|
2020-12-23 19:04:29 +00:00
|
|
|
gdk_array(splice) (&v, pos, remove, FALSE, additions, add);
|
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-02 15:23:09 +00:00
|
|
|
{
|
|
|
|
gsize total = 0;
|
|
|
|
for (j = 0; j < gdk_array(get_size) (&v); j++)
|
|
|
|
total += gdk_array(get) (&v, j);
|
|
|
|
g_assert_cmpint (total, ==, sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), ==, old_size + add - remove);
|
|
|
|
g_assert_cmpint (gdk_array(get_size) (&v), <=, gdk_array(get_capacity) (&v));
|
2020-07-02 21:32:04 +00:00
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
|
|
|
if (gdk_array(get_size) (&v))
|
|
|
|
g_assert_cmpint (*gdk_array(index) (&v, gdk_array(get_size) (&v)), ==, 0);
|
|
|
|
#endif
|
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-02 15:23:09 +00:00
|
|
|
for (j = 0; j < add; j++)
|
|
|
|
g_assert_cmpint (gdk_array(get) (&v, pos + j), ==, additions[j]);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < gdk_array(get_size) (&v); i++)
|
|
|
|
{
|
|
|
|
sum -= gdk_array(get) (&v, i);
|
|
|
|
}
|
|
|
|
g_assert_cmpint (sum, ==, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
#undef _T_
|
|
|
|
#undef GdkArray
|
|
|
|
#undef gdk_array_paste_more
|
|
|
|
#undef gdk_array_paste
|
|
|
|
#undef gdk_array
|
2020-07-02 21:32:04 +00:00
|
|
|
#undef GDK_ARRAY_REAL_SIZE
|
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-02 15:23:09 +00:00
|
|
|
|
|
|
|
#undef GDK_ARRAY_ELEMENT_TYPE
|
|
|
|
#undef GDK_ARRAY_NAME
|
|
|
|
#undef GDK_ARRAY_TYPE_NAME
|
2020-07-02 21:32:04 +00:00
|
|
|
#undef GDK_ARRAY_PREALLOC
|
|
|
|
#undef GDK_ARRAY_NULL_TERMINATED
|
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-02 15:23:09 +00:00
|
|
|
|