After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 419379 - Modernize init_pygobject: use static inline functions instead of macros
Modernize init_pygobject: use static inline functions instead of macros
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: gobject
Git master
Other Linux
: Normal normal
: ---
Assigned To: Gustavo Carneiro
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-17 15:06 UTC by Gustavo Carneiro
Modified: 2007-04-14 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
init_pygobject macro -> static inline pygobject_init (6.13 KB, patch)
2007-03-17 15:09 UTC, Gustavo Carneiro
none Details | Review
patch v2 (6.13 KB, patch)
2007-03-17 16:44 UTC, Gustavo Carneiro
none Details | Review
patch v3: more useful error reporting (6.76 KB, patch)
2007-03-18 13:47 UTC, Gustavo Carneiro
committed Details | Review

Description Gustavo Carneiro 2007-03-17 15:06:56 UTC
init_pygobject is the perfect example of a place where a static inline function is preferable to a macro.  Macros make it more difficult to track down problems (see for instance bug 417004).  And macros that contain 'return' statements are downright evil, with few exceptions.
Comment 1 Gustavo Carneiro 2007-03-17 15:09:51 UTC
Created attachment 84771 [details] [review]
init_pygobject macro -> static inline pygobject_init

Add a pygobject_init static inline function; make the old macros call this function.

I've been using a similar solution in gnome-python/gnomevfs, for some time now, and no one has complained yet of any compilation problems. See http://svn.gnome.org/viewcvs/gnome-python/trunk/gnomevfs/pygnomevfs.h?view=markup
Comment 2 Gustavo Carneiro 2007-03-17 16:44:43 UTC
Created attachment 84773 [details] [review]
patch v2

New version of patch that: 1. returns the module object or NULL instead of 0/-1, 2. Doesn't try to fetch the module dictionary, instead uses PyObject_GetAttrString.
Comment 3 Gustavo Carneiro 2007-03-18 13:47:45 UTC
Created attachment 84821 [details] [review]
patch v3: more useful error reporting
Comment 4 John Ehresman 2007-03-18 16:53:10 UTC
+1

Note that it doesn't even need to be inline as this is not performance critical.  Also, not using the module dictionary is a good thing because it could allow for lazy loading in environments without backward compatibility constraints.
Comment 5 Gustavo Carneiro 2007-03-19 00:08:53 UTC
An important side benefit of inline is that it also (I think) makes a function not compile in for object files that don't use it, thus avoiding duplicated code.  So it's not just a performance issue, also a code size issue.
Comment 6 Gustavo Carneiro 2007-04-14 16:25:33 UTC
Committed revision 643.