Don't keep the lists of source files for libglib, libgobject and
libgio in the VS project files in addition to the canonical location,
the corresponding Makefile.am files.
Instead, generate the corresponding .vcproj files at make dist time
using the C preprocessor, from template files called .vcprojin. We
still list explicitly in the .vcprojin files some of the
Windows-specific source files, and the sources files of gnulib and
pcre.
This adds the two new functions g_type_add_class_private()
and g_type_class_get_private() and a convenience macro
for the getter G_TYPE_CLASS_GET_PRIVATE().
Appease the MS C++ compiler by using _val instead of __value as a variable
name in G_VALUE_COLLECT_INIT.
Problem found by Haakon Sporsheim <haakon.sporsheim@gmail.com>.
Re-closes: bgo#608602
This way we don't need to keep a custom array that we bsearch on (and
that isn't threadsafe) but can use the gtype.c machinery that is
threadsafe. And fast, too!
https://bugzilla.gnome.org/show_bug.cgi?id=554887
This eases cleaning up these functions.
One optimization in value_set_internal() was lost in the process. It
shouldn't cause too many issues when all is said and done.
https://bugzilla.gnome.org/show_bug.cgi?id=554887
It makes the IBM XL C Compiler (the 'native' non-free compiler
on the AIX 5.3 and 6.1 platform) stop compiling with syntax error.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=581300
Signed-off-by: Javier Jardón <jjardon@gnome.org>
The reason we need to enforce this is that the GTypeValueTable
documentation explicitly states that memory is memset to 0 when the
value_init function is called.
https://bugzilla.gnome.org/show_bug.cgi?id=603590
Makes g_signal_emit_valist from 15% to 20% faster.
Results reported from profiling the pan newsreader which uses a variant
of simple and complex signal emissions (i.e no args or various args)
https://bugzilla.gnome.org/show_bug.cgi?id=603590
Most callers of G_VALUE_COLLECT previously had to initialize the GValue
and then G_VALUE_COLLECT would still go through a cleanup phase.
The new variant allows passing a unitialized GValue along with a GType
and speedup the initialization/collection process.
https://bugzilla.gnome.org/show_bug.cgi?id=603590
If threads are available we always enable threads in gobject, which
means all gio/gobject code can enable the unconditional thread calls.
This is a minor optimization since we avoid a bunch of unnecessary
is-threads-enabled checks.
https://bugzilla.gnome.org/show_bug.cgi?id=606775
This works around the need to take a custom mutex twice and add the
object to a GSList of objects that are currently in construction for the
common case. Only when the constructor is overwritten do we use the
previous behavior and allow things like singleton objects.
The only slightly incompatible change is that previously, it was ok to
call g_object_set() on construct-only properties while the object was
initialized. This will now fail. If that behavior is needed, setting a
custom constructor that just chains up will reenable this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=557151
g_type_default_interface_peek() and g_type_value_table_peek() don't need
to acquire read locks anymore when they test the refcount instead of
node->data.
The function returns TRUE if the type was previously initialized and can
be easily reused. It returns FALSE and does not take a reference if the
type is not referenced yet.
g_type_class_ref() uses this to avoid taking locks in the common path,
which speeds up object creation a lot - in particular in multithreaded
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
This does not change any locking behavior at all, it just replaces
simple getters/setters of the variable with atomic versions.
The ref_count variable was kept as unsigned, even though that requires
casting for all operations, to mirror GObject->refcount.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
Currently interface lookups are do a binary search over all the interfaces
an object implements. Its possible to do this lookup in constant time using for
instance the gcj algorighm described at:
http://gcc.gnu.org/ml/java/1999-q3/msg00377.html
This is an implementation of that based on GAtomicArray.
