GNOME Bugzilla – Bug 337128
Macro expansion problems calling G_DEFINE_TYPE_EXTENDED
Last modified: 2006-05-02 14:53:56 UTC
Currently the different G_DEFINE_TYPE macros call G_DEFINE_TYPE_EXTENDED: #define G_DEFINE_TYPE(TN, t_n, T_P) G_DEFINE_TYPE_EXTENDED (TN, t_n, T_P, 0, {}) #define G_DEFINE_TYPE_WITH_CODE(TN, t_n, T_P, _C_) G_DEFINE_TYPE_EXTENDED (TN, t_n, T_P, 0, _C_) #define G_DEFINE_ABSTRACT_TYPE(TN, t_n, T_P) G_DEFINE_TYPE_EXTENDED (TN, t_n, T_P, G_TYPE_FLAG_ABSTRACT, {}) #define G_DEFINE_ABSTRACT_TYPE_WITH_CODE(TN, t_n, T_P, _C_) G_DEFINE_TYPE_EXTENDED (TN, t_n, T_P, G_TYPE_FLAG_ABSTRACT, _C_) This is problematic though, as _C_ is expanded before passing to G_DEFINE_TYPE_EXTENDED, causing compile errors if the code passed in contains any comma tokens! This can be fixed easily, by breaking G_DEFINE_TYPE_EXTENDED into two parts, one before the code and one after, and make _WITH_CODE macros call them and expand _C_ themselves.
Ok, not any comma tokens, but commas not inside parantheses. See bug 337129 for an example of code breaking because of this.
Isn't the usual trick to work around this to add extra () around the _C_ ?
That only works for expressions, which is not the case in G_IMPLEMENT_INTERFACE for example.
behdad, can you provide examples and a patch, so that: a) the example gets broken by commas in the code, b) the patch splits up DEFINE_TYPE as described c) the example works with teh patch applied? i'm asking since i have my doubts that (c) actually occours, because additional commas will already confuse the call to G_DEFINE_TYPE_WITH_CODE(). as for the general buggynedd of commas in code in preprocessor args... there's only so much you can do in C, GObject + preprocessor magic simply isn't a full replacement for native language OO support.
Tim, a) the patch in bug 337129 breaks implementation of any interface using g_DEFINE_TYPE_WITH_CODE (..., G_IMPLEMENT_INTERFACE(...)). b) I'll attach a patch, c) it happens when you pass a macro as the code to G_DEFINE_TYPE_WITH_CODE. For example, G_IMPLEMENT_INTERFACE is such a macro. So it doesn't confuse G_DEFINE_TYPE_WITH_CODE.
Created attachment 63825 [details] test case
Created attachment 63826 [details] [review] patch
ok, thanks for the code Behdad, i see the problem now. your "fix" really only works in the presence of one level of macro nesting, the general problem persists. however that's no reason to not apply your changes as they give one nesting macro level headroom, so i've done that now with some slight cleanups. i've also added your test code, assuming the same license you submitted the patch under.
Thanks Tim. Yeah, no license problem.