Re: NM coding style regarding private gobject data
Hi, it seems the opaque pointer is not faster anymore [1] and, as you said,
wastes one pointer of memory, so what about
nm_type_name_get_instance_private? [1]
[1] https://www.bassi.io/tag/gobject/
--
Álex Puchades
El 29/04/2015 12:00, Thomas Haller thal...@redhat.com escribió:
Hi,
in NM code, we tend to have gobject (duhh) with private data.
We almost always define a macro NM_TYPE_NAME_GET_PRIVATE() as accessor.
I think this long name is quite cumbersome to write. It's a bit redeemed
as we often cache that pointer in a @priv member, but you still have to
add
NMTypeNamePrivate *priv = NM_TYPE_NAME_GET_PRIVATE (self);
to almost all methods.
What do you think about registering an opaque priv pointer in the
public struct instead?
Something like
/* nm-device.h */
struct _NMDevicePrivate;
typedef struct {
GObject parent;
struct _NMDevicePrivate *priv;
} NMDevice;
/* nm-device.c */
typedef struct _NMDevicePrivate NMDevicePrivate;
struct _NMDevicePrivate {
/*members*/
};
#define NM_DEVICE_GET_PRIVATE(self) (self-priv)
so, we can still continue to use NM_DEVICE_GET_PRIVATE(self), but a IMO
nicer way would be just self-priv.
It even has better runtime performance (but consumes one pointer more
memory).
Any opinions?
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM coding style regarding private gobject data
On Wed, 2015-04-29 at 12:36 +0200, Alex Puchades wrote:
Hi, it seems the opaque pointer is not faster anymore [1] and, as you
said, wastes one pointer of memory, so what about
nm_type_name_get_instance_private? [1]
[1] https://www.bassi.io/tag/gobject/
Hi,
Interesting. Thank you for the link.
G_DEFINE_TYPE_WITH_PRIVATE() was added ~only~ in glib 2.38.
We would have to bump our min-version requirement for that.
But my point wasn't performance (or the waste of a pointer instance).
And it wasn't the burden of #define'ing NM_TYPE_NAME_GET_PRIVATE().
It's my personal annoyance with the verboseness of:
NM_TYPE_NAME_GET_PRIVATE (self)-my_field
nm_type_name_get_instance_private (self)-my_field
vs.
self-priv-my_field
Bonus point: it's easier in gdb/debugger.
Thomas
--
Álex Puchades
El 29/04/2015 12:00, Thomas Haller thal...@redhat.com escribió:
Hi,
in NM code, we tend to have gobject (duhh) with private data.
We almost always define a macro NM_TYPE_NAME_GET_PRIVATE() as
accessor.
I think this long name is quite cumbersome to write. It's a
bit redeemed
as we often cache that pointer in a @priv member, but you
still have to
add
NMTypeNamePrivate *priv = NM_TYPE_NAME_GET_PRIVATE (self);
to almost all methods.
What do you think about registering an opaque priv pointer
in the
public struct instead?
Something like
/* nm-device.h */
struct _NMDevicePrivate;
typedef struct {
GObject parent;
struct _NMDevicePrivate *priv;
} NMDevice;
/* nm-device.c */
typedef struct _NMDevicePrivate NMDevicePrivate;
struct _NMDevicePrivate {
/*members*/
};
#define NM_DEVICE_GET_PRIVATE(self) (self-priv)
so, we can still continue to use NM_DEVICE_GET_PRIVATE(self),
but a IMO
nicer way would be just self-priv.
It even has better runtime performance (but consumes one
pointer more
memory).
Any opinions?
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM coding style regarding private gobject data
On Wed, 2015-04-29 at 16:33 +0200, Aleksander Morgado wrote: On Wed, Apr 29, 2015 at 2:49 PM, Thomas Haller thal...@redhat.com wrote: It's my personal annoyance with the verboseness of: NM_TYPE_NAME_GET_PRIVATE (self)-my_field nm_type_name_get_instance_private (self)-my_field vs. self-priv-my_field Bonus point: it's easier in gdb/debugger. I personally also prefer to waste a pointer per object and have self-priv, truth be told, even if the new get_instance_private () macros are pointer arithmetic only. I'm personally fine with self-priv, but ISTR the last time this came up Pavel had some objections to it based around type-safety I think? GET_PRIVATE() does type-checking, while of course direct pointer access doesn't. Or something like that. But of course if GET_PRIVATE() returns NULL and we dereference that to get the private data anyway, it'll still crash just like self-priv on a bogus pointer. In any case, I'm fine with moving in that direction, but we should dig up what Pavel's objection was just for reference. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM coding style regarding private gobject data
On Wed, Apr 29, 2015 at 2:49 PM, Thomas Haller thal...@redhat.com wrote: It's my personal annoyance with the verboseness of: NM_TYPE_NAME_GET_PRIVATE (self)-my_field nm_type_name_get_instance_private (self)-my_field vs. self-priv-my_field Bonus point: it's easier in gdb/debugger. I personally also prefer to waste a pointer per object and have self-priv, truth be told, even if the new get_instance_private () macros are pointer arithmetic only. -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
