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 <glib.h>
|
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
|
|
|
#ifndef GDK_ARRAY_TYPE_NAME
|
|
|
|
#define GDK_ARRAY_TYPE_NAME GdkArray
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef GDK_ARRAY_NAME
|
|
|
|
#define GDK_ARRAY_NAME gdk_array
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef GDK_ARRAY_ELEMENT_TYPE
|
|
|
|
#define GDK_ARRAY_ELEMENT_TYPE gpointer
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GDK_ARRAY_PREALLOC
|
|
|
|
#if GDK_ARRAY_PREALLOC == 0
|
|
|
|
#undef GDK_ARRAY_PREALLOC
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
2020-07-02 21:32:04 +00:00
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
|
|
|
#define GDK_ARRAY_REAL_SIZE(_size) ((_size) + 1)
|
|
|
|
#else
|
|
|
|
#define GDK_ARRAY_REAL_SIZE(_size) (_size)
|
|
|
|
#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
|
|
|
/* make this readable */
|
|
|
|
#define _T_ GDK_ARRAY_ELEMENT_TYPE
|
|
|
|
#define GdkArray GDK_ARRAY_TYPE_NAME
|
|
|
|
#define gdk_array_paste_more(GDK_ARRAY_NAME, func_name) GDK_ARRAY_NAME ## _ ## func_name
|
|
|
|
#define gdk_array_paste(GDK_ARRAY_NAME, func_name) gdk_array_paste_more (GDK_ARRAY_NAME, func_name)
|
|
|
|
#define gdk_array(func_name) gdk_array_paste (GDK_ARRAY_NAME, func_name)
|
|
|
|
|
|
|
|
typedef struct GdkArray GdkArray;
|
|
|
|
|
|
|
|
struct GdkArray
|
|
|
|
{
|
|
|
|
_T_ *start;
|
|
|
|
_T_ *end;
|
|
|
|
_T_ *end_allocation;
|
|
|
|
#ifdef GDK_ARRAY_PREALLOC
|
2020-07-02 21:32:04 +00:00
|
|
|
_T_ preallocated[GDK_ARRAY_REAL_SIZE(GDK_ARRAY_PREALLOC)];
|
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
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
/* no G_GNUC_UNUSED here, if you don't use an array type, remove it. */
|
|
|
|
static inline void
|
|
|
|
gdk_array(init) (GdkArray *self)
|
|
|
|
{
|
|
|
|
#ifdef GDK_ARRAY_PREALLOC
|
|
|
|
self->start = self->preallocated;
|
|
|
|
self->end = self->start;
|
|
|
|
self->end_allocation = self->start + GDK_ARRAY_PREALLOC;
|
2020-07-02 21:32:04 +00:00
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
2020-07-24 08:25:24 +00:00
|
|
|
*self->start = *(_T_[1]) { 0 };
|
2020-07-02 21:32:04 +00:00
|
|
|
#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
|
|
|
#else
|
|
|
|
self->start = NULL;
|
|
|
|
self->end = NULL;
|
|
|
|
self->end_allocation = NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
gdk_array(free_elements) (_T_ *start,
|
|
|
|
_T_ *end)
|
|
|
|
{
|
|
|
|
#ifdef GDK_ARRAY_FREE_FUNC
|
|
|
|
_T_ *e;
|
|
|
|
for (e = start; e < end; e++)
|
2020-07-16 14:33:14 +00:00
|
|
|
#ifdef GDK_ARRAY_BY_VALUE
|
|
|
|
GDK_ARRAY_FREE_FUNC (e);
|
|
|
|
#else
|
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
|
|
|
GDK_ARRAY_FREE_FUNC (*e);
|
|
|
|
#endif
|
2020-07-16 14:33:14 +00:00
|
|
|
#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
|
|
|
}
|
|
|
|
|
|
|
|
/* no G_GNUC_UNUSED here */
|
|
|
|
static inline void
|
|
|
|
gdk_array(clear) (GdkArray *self)
|
|
|
|
{
|
|
|
|
gdk_array(free_elements) (self->start, self->end);
|
|
|
|
|
|
|
|
#ifdef GDK_ARRAY_PREALLOC
|
|
|
|
if (self->start != self->preallocated)
|
|
|
|
#endif
|
|
|
|
g_free (self->start);
|
|
|
|
gdk_array(init) (self);
|
|
|
|
}
|
|
|
|
|
|
|
|
G_GNUC_UNUSED static inline _T_ *
|
2020-07-16 14:33:14 +00:00
|
|
|
gdk_array(get_data) (const GdkArray *self)
|
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
|
|
|
{
|
|
|
|
return self->start;
|
|
|
|
}
|
|
|
|
|
|
|
|
G_GNUC_UNUSED static inline _T_ *
|
2020-07-16 14:33:14 +00:00
|
|
|
gdk_array(index) (const GdkArray *self,
|
|
|
|
gsize pos)
|
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
|
|
|
{
|
|
|
|
return self->start + pos;
|
|
|
|
}
|
|
|
|
|
|
|
|
G_GNUC_UNUSED static inline gsize
|
2020-07-16 14:33:14 +00:00
|
|
|
gdk_array(get_capacity) (const GdkArray *self)
|
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
|
|
|
{
|
|
|
|
return self->end_allocation - self->start;
|
|
|
|
}
|
|
|
|
|
|
|
|
G_GNUC_UNUSED static inline gsize
|
2020-07-16 14:33:14 +00:00
|
|
|
gdk_array(get_size) (const GdkArray *self)
|
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
|
|
|
{
|
|
|
|
return self->end - self->start;
|
|
|
|
}
|
|
|
|
|
|
|
|
G_GNUC_UNUSED static inline gboolean
|
2020-07-16 14:33:14 +00:00
|
|
|
gdk_array(is_empty) (const GdkArray *self)
|
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
|
|
|
{
|
|
|
|
return self->end == self->start;
|
|
|
|
}
|
|
|
|
|
2020-09-29 13:57:33 +00:00
|
|
|
G_GNUC_UNUSED static inline void
|
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
|
|
|
gdk_array(reserve) (GdkArray *self,
|
|
|
|
gsize n)
|
|
|
|
{
|
|
|
|
gsize new_size, size;
|
|
|
|
|
|
|
|
if (n <= gdk_array(get_capacity) (self))
|
|
|
|
return;
|
|
|
|
|
|
|
|
size = gdk_array(get_size) (self);
|
2020-07-02 21:32:04 +00:00
|
|
|
new_size = 1 << g_bit_storage (MAX (GDK_ARRAY_REAL_SIZE (n), 16) - 1);
|
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
|
|
|
|
|
|
|
#ifdef GDK_ARRAY_PREALLOC
|
|
|
|
if (self->start == self->preallocated)
|
|
|
|
{
|
|
|
|
self->start = g_new (_T_, new_size);
|
2020-07-02 21:32:04 +00:00
|
|
|
memcpy (self->start, self->preallocated, sizeof (_T_) * GDK_ARRAY_REAL_SIZE (size));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
|
|
|
if (self->start == NULL)
|
|
|
|
{
|
|
|
|
self->start = g_new (_T_, new_size);
|
2020-07-24 08:25:24 +00:00
|
|
|
*self->start = *(_T_[1]) { 0 };
|
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
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
self->start = g_renew (_T_, self->start, new_size);
|
|
|
|
|
|
|
|
self->end = self->start + size;
|
|
|
|
self->end_allocation = self->start + new_size;
|
2020-07-02 21:32:04 +00:00
|
|
|
#ifdef GDK_ARRAY_NULL_TERMINATED
|
|
|
|
self->end_allocation--;
|
|
|
|
#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
|
|
|
}
|
|
|
|
|
2020-09-29 13:57:33 +00:00
|
|
|
G_GNUC_UNUSED static inline void
|
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
|
|
|
gdk_array(splice) (GdkArray *self,
|
|
|
|
gsize pos,
|
|
|
|
gsize removed,
|
2020-12-23 19:04:29 +00:00
|
|
|
gboolean stolen,
|
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
|
|
|
_T_ *additions,
|
|
|
|
gsize added)
|
|
|
|
{
|
2020-07-02 21:32:04 +00:00
|
|
|
gsize size;
|
|
|
|
gsize remaining;
|
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
|
|
|
|
2020-07-02 21:32:04 +00:00
|
|
|
size = gdk_array(get_size) (self);
|
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 (pos + removed <= size);
|
2020-07-02 21:32:04 +00:00
|
|
|
remaining = size - pos - removed;
|
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
|
|
|
|
2020-12-23 19:04:29 +00:00
|
|
|
if (!stolen)
|
|
|
|
gdk_array(free_elements) (gdk_array(index) (self, pos),
|
|
|
|
gdk_array(index) (self, pos + removed));
|
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
|
|
|
|
|
|
|
gdk_array(reserve) (self, size - removed + added);
|
|
|
|
|
2020-07-02 21:32:04 +00:00
|
|
|
if (GDK_ARRAY_REAL_SIZE (remaining) && removed != added)
|
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
|
|
|
memmove (gdk_array(index) (self, pos + added),
|
|
|
|
gdk_array(index) (self, pos + removed),
|
2020-07-02 21:32:04 +00:00
|
|
|
GDK_ARRAY_REAL_SIZE (remaining) * sizeof (_T_));
|
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
|
|
|
|
|
|
|
if (added)
|
2020-07-16 14:33:14 +00:00
|
|
|
{
|
|
|
|
if (additions)
|
|
|
|
memcpy (gdk_array(index) (self, pos),
|
|
|
|
additions,
|
|
|
|
added * sizeof (_T_));
|
2020-09-29 14:00:30 +00:00
|
|
|
#ifndef GDK_ARRAY_NO_MEMSET
|
2020-07-16 14:33:14 +00:00
|
|
|
else
|
|
|
|
memset (gdk_array(index) (self, pos), 0, added * sizeof (_T_));
|
2020-09-29 14:00:30 +00:00
|
|
|
#endif
|
2020-07-16 14:33:14 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
/* might overflow, but does the right thing */
|
|
|
|
self->end += added - removed;
|
|
|
|
}
|
|
|
|
|
2020-07-16 14:33:14 +00:00
|
|
|
G_GNUC_UNUSED static void
|
|
|
|
gdk_array(set_size) (GdkArray *self,
|
|
|
|
gsize new_size)
|
|
|
|
{
|
|
|
|
gsize old_size = gdk_array(get_size) (self);
|
|
|
|
if (new_size > old_size)
|
2020-12-23 19:04:29 +00:00
|
|
|
gdk_array(splice) (self, old_size, 0, FALSE, NULL, new_size - old_size);
|
2020-07-16 14:33:14 +00:00
|
|
|
else
|
2020-12-23 19:04:29 +00:00
|
|
|
gdk_array(splice) (self, new_size, old_size - new_size, FALSE, NULL, 0);
|
2020-07-16 14:33:14 +00:00
|
|
|
}
|
|
|
|
|
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_GNUC_UNUSED static void
|
|
|
|
gdk_array(append) (GdkArray *self,
|
2020-07-16 14:33:14 +00:00
|
|
|
#ifdef GDK_ARRAY_BY_VALUE
|
|
|
|
_T_ *value)
|
|
|
|
#else
|
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
|
|
|
_T_ value)
|
2020-07-16 14:33:14 +00:00
|
|
|
#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
|
|
|
{
|
|
|
|
gdk_array(splice) (self,
|
|
|
|
gdk_array(get_size) (self),
|
|
|
|
0,
|
2020-12-23 19:04:29 +00:00
|
|
|
FALSE,
|
2020-07-16 14:33:14 +00:00
|
|
|
#ifdef GDK_ARRAY_BY_VALUE
|
|
|
|
value,
|
|
|
|
#else
|
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
|
|
|
&value,
|
2020-07-16 14:33:14 +00:00
|
|
|
#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
|
|
|
1);
|
|
|
|
}
|
|
|
|
|
2020-07-16 14:33:14 +00:00
|
|
|
#ifdef GDK_ARRAY_BY_VALUE
|
|
|
|
G_GNUC_UNUSED static _T_ *
|
|
|
|
gdk_array(get) (const GdkArray *self,
|
|
|
|
gsize pos)
|
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
|
|
|
{
|
2020-07-16 14:33:14 +00:00
|
|
|
return gdk_array(index) (self, pos);
|
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
|
|
|
}
|
2020-07-16 14:33:14 +00:00
|
|
|
#else
|
|
|
|
G_GNUC_UNUSED static _T_
|
|
|
|
gdk_array(get) (const GdkArray *self,
|
|
|
|
gsize pos)
|
|
|
|
{
|
|
|
|
return *gdk_array(index) (self, pos);
|
|
|
|
}
|
|
|
|
#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
|
|
|
|
|
|
|
#ifndef GDK_ARRAY_NO_UNDEF
|
|
|
|
|
|
|
|
#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
|
|
|
|
2020-07-16 14:33:14 +00:00
|
|
|
#undef GDK_ARRAY_BY_VALUE
|
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
|
2020-07-16 14:33:14 +00:00
|
|
|
#undef GDK_ARRAY_FREE_FUNC
|
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_NAME
|
2020-07-02 21:32:04 +00:00
|
|
|
#undef GDK_ARRAY_NULL_TERMINATED
|
2020-07-16 14:33:14 +00:00
|
|
|
#undef GDK_ARRAY_PREALLOC
|
|
|
|
#undef GDK_ARRAY_TYPE_NAME
|
2020-09-29 14:00:30 +00:00
|
|
|
#undef GDK_ARRAY_NO_MEMSET
|
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
|
|
|
#endif
|