Commit Graph

103 Commits

Author SHA1 Message Date
Matthias Clasen
47c12389a0 gobject: Speed up property lookup
When the param specs are provided as an array
with g_object_class_install_properties, keep
a copy of that array around and use it for
looking up properties without the param spec
pool.

Note that this is an opportunistic optimization -
currently, it only works for properties of the
class itself, not for parent classes, and it
only works if the property names are identical
string literals (we're at the mercy of the linker
for that).

If we don't get lucky, we fall back to using
the pspec pool as usual.
2022-06-07 12:39:58 -04:00
Matthias Clasen
f7119a7935 Keep a count of construct params
This avoids walking the construct params list
one extra time just to count when constructing
objects, for a small speedup of object construction
in the presence of construct params.
2022-05-26 09:47:23 -04:00
Philip Withnall
7a8756d247 gobject: Add advice on larger alignment requirements for GObject members
We now guarantee that GObjects will always be allocated at least as
aligned as the basic types. If you want to put an element in your
GObject which has higher alignment requirements, we can’t guarantee it
will be aligned*. If you need it to be aligned, you’ll need to put it on
the heap (aligned appropriately), or add appropriate padding in your
GObject struct.

*Actually, GSlice will guarantee that the whole GObject is aligned to at
least the power of 2 greater than or equal to the size of the GObject,
which means any element in the GObject struct should always be
appropriate aligned if the compiler pads it appropriately. If malloc()
is used, however, it doesn’t make that guarantee, so we can’t make that
guarantee overall.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1231
2021-11-17 11:56:20 +00:00
Philip Withnall
0749643daa gobject: Assert that GObjects are at least as aligned as basic types
See the reasoning in the patch for why we believe GObjects *are*
(already) as aligned as the basic types.

We want to make this guarantee so that it’s guaranteed to be safe for
people to ignore -Wcast-align warnings for GObjects which contain basic
types. This typically happens with gdouble on 32-bit ARM platforms.

The checks are slightly complicated by the need to support GObjects with
custom constructors. We should expect that a custom construction
function will chain up to g_object_constructor (which calls
g_type_create_instance() as normal), but it’s possible that someone has
done something crazy and uses a custom allocator which doesn’t return
with the same alignment as GSlice. Hand them a warning in that case. If
that is true, the code which uses their custom-constructed GObject can
presumably already deal with the alignment it gets given.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1231
2021-11-17 11:56:20 +00:00
Philip Withnall
0d57092a03 gobject: Document it’s unsafe to call g_object_ref() from GWeakNotify
The documentation sort of already said this, but it’s better to make it
explicit.

This avoids the situation where some of the weak notify callbacks for an
object have been called, and then a subsequent one resurrects the
object. Without some way of undoing the weak notifications already sent,
that would leave external state which is coupled to the object’s
lifecycle out of sync.

This arose from discussion on !2064.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-09-15 15:02:47 +01:00
Emmanuele Bassi
f62622fc7b docs: Start stanzas with a single paragraph
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.

The documentation is assumed to be in Markdown format, which means:

 - paragraphs must be separated by newlines
 - lines that have an indentation of four or more spaces are considered
   code blocks
 - lines that start with a `#` are considered titles

This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.

See issue: #2365
2021-08-02 13:22:23 +01:00
Philip Withnall
b95d9d1db6 Merge branch 'g_obj_take_ref' into 'main'
GObject: add g_object_take_ref()

Closes #1112

See merge request GNOME/glib!2146
2021-06-15 11:28:00 +00:00
Allison Ryan Lortie
3764c6730e GObject: add g_object_take_ref()
This works in the same way as g_variant_take_ref(), and for the same
reason.

Updated and Rebased by Nitin Wartkar <nitinwartkar58@gmail.com>

Closes #1112
2021-06-11 18:13:34 +05:30
Xavier Claessens
090d65712d glib_typeof: Move definition to its own header
It is cleaner to define glib_typeof() in a header included after
gversionmacros.h so we can use GLIB_VERSION_MIN_REQUIRED directly
instead of doing it everywhere glib_typeof() is used.
2021-05-17 12:07:30 -04:00
Iain Lane
552b8fd862
glib/gmacros.h: Move <type_traits> include to consumers
When included inside an `extern "C"` block, this causes build failures
that look something like:

  /usr/include/c++/10/type_traits:2930:3: error: template with C linkage
   2930 |   template<typename _Fn, typename... _Args>
        |   ^~~~~~~~
  ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
     20 | extern "C" {
        | ^~~~~~~~~~

Commit 4273c43902 made this opt in for
projects which are defining `GLIB_VERSION_MIN_REQUIRED`, but the include
of `<type_traits>` via `gmacros.h` was not included in this. If we move
the include out to the places where `glib_typeof` is called, we can make
it covered by this macro too, and save a few consumers from FTBFSing.

That also means that, if you don't want to fix your use of the headers,
and as long as this version is sufficient for you, a quick workaround is
to define `GLIB_VERSION_MIN_REQUIRED` to `GLIB_VERSION_2_66` or lower.

Suggested by Simon McVittie.

Alternative to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2331
2021-02-25 15:33:59 +00:00
Xavier Claessens
4273c43902 glib_typeof: It is an API break that should be opt-in
That changes the return type of functions like g_object_ref() that can
break C++ applications like Webkit. Note that it is not an ABI break.

It must thus be opt-in the same way we did when adding this to
g_object_ref() for GNU C compilers in the first place. Unfortunately it
cannot be done directly in gmacros.h because GLIB_VERSION_2_68 is not
defined there, and gversionmacros.h cannot be included there because
there is some strict ordering in which those headers must be included.

This means that applications that does not define
GLIB_VERSION_MIN_REQUIRED will still get an API break, so we encourage
them to declare their minimum requirement to avoir such issues in the
future too.
2021-01-27 09:26:39 -05:00
Sebastian Dröge
a2de4b2479 Clarify in g_object_weak_ref() docs that the callback is called during disposing and not finalizing
This especially has the effect that any GWeakRefs to the object will not
necessarily be set to NULL yet if called as part of
g_object_run_dispose() and not as part of g_object_unref().
2020-12-08 18:09:50 +02:00
Philip Withnall
334f695336 gobject: Drop volatile qualifier from GObject.ref_count
This is an API break, but no third party code should be touching
`GObject.ref_count`, let alone in a way which would be changed by the
removal of the `volatile` qualifier.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #600
2020-11-20 14:40:19 +00:00
Philip Withnall
a65fe37e5c gobject: Clarify documentation and annotations of g_set_object()
Heavily based on changes suggested by Дилян Палаузов.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #1849
2020-11-14 20:35:09 +00:00
Xavier Claessens
5b2bee3f53 Replace __typeof__ with glib_typeof macro
g_has_typeof macro is wrongly in the public g_ namespace, internaly
symbols are usually in the glib_ namespace. This will also allow to
define glib_typeof differently on non-GNUC compilers (e.g. c++11
decltype).
2020-10-14 14:48:36 -04:00
Philip Withnall
00bfb3ab44 tree: Fix various typos and outdated terminology
This was mostly machine generated with the following command:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).

Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.

There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.

If I’ve missed anything, please file an issue!

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-06-12 15:01:08 +01:00
Philip Withnall
51acb01f73 gobject: Fix strict aliasing warnings with g_set_object()
When calling `g_set_object()` for a type derived from `GObject`, GCC 9.2
was giving the following strict aliasing warning:
```
../../source/malcontent/libmalcontent-ui/user-controls.c:1001:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
 1001 |   if (g_set_object (&self->user, user))
/opt/gnome/install/include/glib-2.0/gobject/gobject.h:744:33: note: in definition of macro ‘g_set_object’
  744 |   (g_set_object) ((GObject **) (object_ptr), (GObject *) (new_object)) \
      |                                 ^~~~~~~~~~
```

This was due to the `(GObject **)` cast.

Pass the pointer through a union to squash this warning. We already do
some size and type checks of the dereferenced type, which should catch
casual errors. The `g_object_ref()` and `g_object_unref()` calls which
subsequently happen inside the `g_set_object()` function also do some
dynamic type checks.

Add a test.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-02-18 12:15:52 +00:00
Simon McVittie
b76bf3ca72 gobject: Add a g_assert_finalize_object() macro
With modifications by Philip Withnall.

Fixes: #488
2019-07-25 15:23:21 +01:00
Xavier Claessens
5c9af3c75c doc: Add some empty lines to unbreak gtkdoc
For some reason gtkdoc thinks g_test_trap_fork() is undefined, unless
some more spacing is added.
2019-07-10 10:10:49 -04:00
Philip Withnall
40ff475977 Annotate various types and macros as deprecated
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.

This is based on the list of deprecations from the reverted commit
80fcb1bc2.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #638
2019-05-30 10:39:11 +01:00
Iain Lane
4c621fb7ee gmacros: Add new private g_has_typeof to abstract __typeof__ checks
We have this same check in a few places now, and we might as well
abstract it out.

Fixes #1440.
2018-07-16 15:59:44 +01:00
Iain Lane
2aacef39b1 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-12 08:47:40 +01:00
Emmanuele Bassi
d3881bb1bf Revert "Merge branch 'type-safe-g-clear-pointer-1425' into 'master'"
This reverts merge request !165
2018-07-11 21:52:31 +00:00
Iain Lane
747c2f5720 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-11 10:52:53 +01:00
Fabrice Fontaine
b93788ac13 gobject: fix compilation with gcc <= 4.7
On gcc 4.7, we got the following error:

i686-nptl-linux-gnu-gcc --version
> i686-nptl-linux-gnu-gcc (crosstool-NG 1.20.0) 4.7.4
> $ echo '#include <glib-object.h>' | i686-nptl-linux-gnu-gcc -x c -I
staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
-Werror -c - -o /tmp/foo.o
> In file included from
staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>                  from staging/usr/include/glib-2.0/glib-object.h:23,
>                  from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function
'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value
computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors

This error has been added by commit 3fae39a5d7
So enable the new g_set_object definition only if gcc >= 4.8

Fixes:
 - http://autobuild.buildroot.net/results/b29a2f868438a2210873ea72f491db63175848be

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

https://bugzilla.gnome.org/show_bug.cgi?id=795138
2018-04-20 11:28:42 +01:00
Philip Withnall
7c2fd10fe4 docs: Remove some latent DocBook usage in the GObjectClass documentation
Replace it with gtk-doc syntax.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-01-05 16:44:18 +00:00
Martin Blanchard
156d32cb80 gobject: new g_set_weak_pointer() & g_clear_weak_pointer() helpers
Weak-pointers are currently lacking g_set_object() & g_clear_object()
helpers equivalent. New functions (and macros, both are provided) are
convenient in many case, especially for the property's notify-on-set
pattern:

  if (g_set_weak_pointer (...))
    g_object_notify (...)

Inspired by Christian Hergert's original implementation for
gnome-builder.

https://bugzilla.gnome.org/show_bug.cgi?id=749527
2017-12-21 09:59:30 +00:00
Emmanuele Bassi
1a6f6487b7 Disable refcounting type propagation with C++
The type propagation breaks the GRefPtr.h class in WebKitGTK, and in
any case existing C++ code calling the C API will need to perform an
explicit cast, as there's no automatic promotion of pointer types to
and from void*.

Tested-by: GNOME Continuous

https://bugzilla.gnome.org/show_bug.cgi?id=790697
2017-12-09 00:57:59 +00:00
Emmanuele Bassi
9f3f089e60 Use escaped version of typeof
When compiling code that includes gobject.h using GCC with the ISO
standard, the `typeof` keyword is disabled, as it's a GCC extension.

The GCC documentation recommends:

> If you are writing a header file that must work when included in
> ISO C programs, write __typeof__ instead of typeof.

Which is precisely what we're going to do.

Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=790697
2017-12-08 12:56:55 +00:00
Christian Hergert
3fae39a5d7 gobject: add type propagation to gobject ref API
Currently, g_object_ref() and g_object_ref_sink() return a
gpointer which can mask issues when assigning to fields or
returning from a function.

To help catch these type of programming errors, we can propagate
the type of the parameter through the function call on GCC
using the typeof() C language extension.

This will cause offending code to have a warning, but will
continue to be source and binary compatible.

This is only enabled when GLIB_VERSION_MAX_ALLOWED is 2.56 or greater.

https://bugzilla.gnome.org/show_bug.cgi?id=790697
2017-12-08 11:14:52 +00:00
Sébastien Wilmet
6b948d9613 gobject/: LGPLv2+ -> LGPLv2.1+
All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Philip Withnall
2f2c2b6362 gobject: Fix Since/Deprecated versions for GParameter replacement API
This slipped through the review cracks.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 11:09:53 +01:00
Fabian Orccon
e2c3b7f634 gobject: Deprecate g_object_newv
g_object_newv uses a GParameter as argument. Since GParameter
is deprecated due to this type is not introspectible,
g_object_newv is deprecated now.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 11:00:23 +01:00
Fabian Orccon
c6d373bfe7 gobject: Add g_object_setv and g_object_getv functions
https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 10:38:30 +01:00
Fabian Orccon
26b211ef89 gobject: Add g_object_new_with_properties
g_object_new_with_properties is an alternative to g_object_newv.
The last one, takes an array of GParameter. However, GParameter
is a rarely used type and this type is not introspectible, so
it will not work properly in bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 10:38:30 +01:00
Matthias Clasen
087d75e3c3 Make g_set_object more symmetric
As argued in bug 748633, and order of ref, assign, unref is
preferable.
2015-09-07 19:43:19 -04:00
David King
d36f6a9633 gobject.h: Use correct format specifier for __LINE__
GCC 5.0, with its new -Wformat-signedness, warns about the sign being
different between a type and the format string in printf-format
messages, leading to compiler warnings with G_OBJECT_WARN_INVALID_PSPEC.
In other uses of __LINE__ inside GLib, %d is used, and GCC seems to
expect a format specifier of %d as well:
https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html

https://bugzilla.gnome.org/show_bug.cgi?id=744263
2015-02-26 12:32:43 +01:00
Thomas Haller
c447bc7f93 gobject: don't use G_STRLOC in G_OBJECT_WARN_INVALID_PSPEC() macro
Using G_STRLOC ends up embedding unique strings of the form
__FILE__:__LINE__ in the compiled binary. We can avoid these
by passing __FILE__ and __LINE__ separately when constructing
the warning text.
This probably reduces the size of the binary as __FILE__ is
likely already contained as string otherwise.

Note that for GCC 2.x this changes behavior because G_STRLOC
also contained __PRETTY_FUNCTION__.

https://bugzilla.gnome.org/show_bug.cgi?id=741654
2014-12-18 15:02:16 +01:00
Philip Withnall
d951db4236 gobject: Add g_set_object() convenience function to set GObject pointers
Along the same lines as g_clear_object(), g_set_object() is a
convenience function to update a GObject pointer, handling reference
counting transparently and correctly.

Specifically, it handles the case where a pointer is set to its current
value. If handled naïvely, that could result in the object instance
being finalised. In the following code, that happens when
(my_obj == new_value) and the object has a single reference:
    g_clear_object (&my_obj);
    my_obj = g_object_ref (new_value);

It also simplifies boilerplate code such as set_property()
implementations, which are otherwise long and boring.

Test cases included.

https://bugzilla.gnome.org/show_bug.cgi?id=741589
2014-12-18 11:32:56 +00:00
Ryan Lortie
d558e87c65 gtype: guard uses of new fundamental type check
g_type_is_fundamentally_a (see bug 730984) is a new API/ABI and is
marked with a version macro.  We should therefore avoid its
unconditional use from G_IS_OBJECT() and G_IS_PARAM_SPEC() which are
APIs that have been around for a long time.

This prevents deprecation warnings from being emitted when these
functions are used with an older GLIB_VERSION_MAX_ALLOWED and also
prevents linking to the new ABI in that case (so that it's possible to
use the resulting binary with an older version of GLib).

https://bugzilla.gnome.org/show_bug.cgi?id=731335
2014-06-06 10:49:29 -04:00
Edward Hervey
faceb8960b gobject: Use fast fundamental instance type check
Speeds up g_object_ref/_unref by 50%-65% (i.e. takes 60-65% of the time
it used to take).

https://bugzilla.gnome.org/show_bug.cgi?id=730984
2014-05-31 15:46:21 +02:00
Matthias Clasen
7a6dfd75d6 GObject: Remove more leftover markup from headers 2014-03-07 06:10:36 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Dan Winship
4b94c0831e Use 'dumb quotes' rather than `really dumb quotes'
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.

However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.

Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.

Fix this by just using 'dumb quotes' everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=700746
2013-05-21 11:23:22 -03:00
Sébastien Wilmet
e3c2d03092 Doc: clarify set_property() vfunc
Implementations "don't need to ...". It was not clear what happen
if they do it all the same.

https://bugzilla.gnome.org/show_bug.cgi?id=695887
2013-03-15 09:07:30 +01:00
Ryan Lortie
0156092a42 various: add GLIB_AVAILABLE_IN_ALL everywhere else
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).

If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=688681
2013-01-13 13:11:57 -05:00
Matthias Clasen
e1b99b2ddc Move single-include guards inside include guards
gcc has optimizations for include guards that only work
if they are outermost in the the header.
https://bugzilla.gnome.org/show_bug.cgi?id=689810
2012-12-27 23:43:14 -05:00
Colin Walters
33de093b5a gobject: Use local variable names in macros less likely to clash
At least GDBus had code that had "_object" as a parameter to one of
its functions, but this clashes with the GObject macro
G_OBJECT_WARN_INVALID_PROPERTY_ID() which created a local "_object".

Since many of us cargo cult around copies of objects, let's be
defensive here and use local variable names less likely to clash with
application code.

https://bugzilla.gnome.org/show_bug.cgi?id=689377
2012-12-05 13:30:14 -05:00
Matthias Clasen
1254ca716b Add an atomic compare-and-exchange operation for object data
This is useful when using object data in thread-safe libraries.

https://bugzilla.gnome.org/show_bug.cgi?id=682849
2012-09-02 15:09:13 -04:00
Xavier Claessens
00285b7517 Add g_clear_pointer()
Also reimplement g_clear_object() using g_clear_pointer()

https://bugzilla.gnome.org/show_bug.cgi?id=674634
2012-04-27 09:42:29 +02:00