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

286 lines
6.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
gdk/gdkarrayimpl.c: Fix build on Visual Studio 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.
2020-07-24 08:25:24 +00:00
*self->start = *(_T_[1]) { 0 };
array: Add null-termination
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++)
array: Add a bunch of new features * 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
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
array: Add a bunch of new features * 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
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_ *
array: Add a bunch of new features * 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
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_ *
array: Add a bunch of new features * 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
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
array: Add a bunch of new features * 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
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
array: Add a bunch of new features * 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
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
array: Add a bunch of new features * 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
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;
}
gdkarray: Inline splice and reserve This inlines the splice and reserver GdkArray calls. These are typically only called from the gdk_array_(append/set_size) functions anyway, and inlining the caller means we can constant propagate the constant arguments in those calls. Its hard to get exact numbers, but in fishbowl i noticed a significant decrease in the time spent in the array code when pushing and poping states.
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);
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);
gdk/gdkarrayimpl.c: Fix build on Visual Studio 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.
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;
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
}
gdkarray: Inline splice and reserve This inlines the splice and reserver GdkArray calls. These are typically only called from the gdk_array_(append/set_size) functions anyway, and inlining the caller means we can constant propagate the constant arguments in those calls. Its hard to get exact numbers, but in fishbowl i noticed a significant decrease in the time spent in the array code when pushing and poping states.
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,
_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)
array: Add a bunch of new features * 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
2020-07-16 14:33:14 +00:00
{
if (additions)
memcpy (gdk_array(index) (self, pos),
additions,
added * sizeof (_T_));
gdkarray: Add support for GDK_ARRAY_NO_MEMSET If all your callers already initialize the array element as needed, then we don't need to memset it to zero first. This is pretty useful for the snapshot state stack, because due to the per-node-type data area the elements on the stack are quite large, but often a lot of it is not used.
2020-09-29 14:00:30 +00:00
#ifndef GDK_ARRAY_NO_MEMSET
array: Add a bunch of new features * 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
2020-07-16 14:33:14 +00:00
else
memset (gdk_array(index) (self, pos), 0, added * sizeof (_T_));
gdkarray: Add support for GDK_ARRAY_NO_MEMSET If all your callers already initialize the array element as needed, then we don't need to memset it to zero first. This is pretty useful for the snapshot state stack, because due to the per-node-type data area the elements on the stack are quite large, but often a lot of it is not used.
2020-09-29 14:00:30 +00:00
#endif
array: Add a bunch of new features * 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
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;
}
array: Add a bunch of new features * 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
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)
gdk_array(splice) (self, old_size, 0, NULL, new_size - old_size);
else
gdk_array(splice) (self, new_size, old_size - new_size, NULL, 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
G_GNUC_UNUSED static void
gdk_array(append) (GdkArray *self,
array: Add a bunch of new features * 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
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)
array: Add a bunch of new features * 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
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,
array: Add a bunch of new features * 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
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,
array: Add a bunch of new features * 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
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);
}
array: Add a bunch of new features * 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
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
{
array: Add a bunch of new features * 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
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
}
array: Add a bunch of new features * 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
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
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
array: Add a bunch of new features * 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
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
array: Add a bunch of new features * 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
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
array: Add null-termination
2020-07-02 21:32:04 +00:00
#undef GDK_ARRAY_NULL_TERMINATED
array: Add a bunch of new features * 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
2020-07-16 14:33:14 +00:00
#undef GDK_ARRAY_PREALLOC
#undef GDK_ARRAY_TYPE_NAME
gdkarray: Add support for GDK_ARRAY_NO_MEMSET If all your callers already initialize the array element as needed, then we don't need to memset it to zero first. This is pretty useful for the snapshot state stack, because due to the per-node-type data area the elements on the stack are quite large, but often a lot of it is not used.
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
Reference in New Issue Copy Permalink