AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
088b5fc57f
gtk2/gdk/gdkarrayimpl.c

245 lines
5.7 KiB
C
Raw Normal View History

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
array: Add null-termination
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
array: Add null-termination
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;
array: Add null-termination
2020-07-02 21:32:04 +00:00
#ifdef GDK_ARRAY_NULL_TERMINATED
*self->start = *(_T_[1]) {};
#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++)
GDK_ARRAY_FREE_FUNC (*e);
#endif
}
/* 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_ *
gdk_array(get_data) (GdkArray *self)
{
return self->start;
}
G_GNUC_UNUSED static inline _T_ *
gdk_array(index) (GdkArray *self,
gsize pos)
{
return self->start + pos;
}
G_GNUC_UNUSED static inline gsize
gdk_array(get_capacity) (GdkArray *self)
{
return self->end_allocation - self->start;
}
G_GNUC_UNUSED static inline gsize
gdk_array(get_size) (GdkArray *self)
{
return self->end - self->start;
}
G_GNUC_UNUSED static inline gboolean
gdk_array(is_empty) (GdkArray *self)
{
return self->end == self->start;
}
G_GNUC_UNUSED static void
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);
array: Add null-termination
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);
array: Add null-termination
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);
*self->start = *(_T_[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
}
else
#endif
self->start = g_renew (_T_, self->start, new_size);
self->end = self->start + size;
self->end_allocation = self->start + new_size;
array: Add null-termination
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
}
G_GNUC_UNUSED static void
gdk_array(splice) (GdkArray *self,
gsize pos,
gsize removed,
_T_ *additions,
gsize added)
{
array: Add null-termination
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
array: Add null-termination
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);
array: Add null-termination
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
gdk_array(free_elements) (gdk_array(index) (self, pos),
gdk_array(index) (self, pos + removed));
gdk_array(reserve) (self, size - removed + added);
array: Add null-termination
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),
array: Add null-termination
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)
memcpy (gdk_array(index) (self, pos),
additions,
added * sizeof (_T_));
/* might overflow, but does the right thing */
self->end += added - removed;
}
G_GNUC_UNUSED static void
gdk_array(append) (GdkArray *self,
_T_ value)
{
gdk_array(splice) (self,
gdk_array(get_size) (self),
0,
&value,
1);
}
G_GNUC_UNUSED static _T_
gdk_array(get) (GdkArray *self,
gsize pos)
{
return *gdk_array(index) (self, pos);
}
#ifndef GDK_ARRAY_NO_UNDEF
#undef _T_
#undef GdkArray
#undef gdk_array_paste_more
#undef gdk_array_paste
#undef gdk_array
array: Add null-termination
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
array: Add null-termination
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
#endif
Reference in New Issue Copy Permalink