GNOME Bugzilla – Bug 664618
G_PRIVATE_INIT() causes a compiler warning with g++
Last modified: 2018-05-24 13:31:43 UTC
Using G_PRIVATE_INIT() causes this warning with g++: " extended initializer lists only available with -std=c++0x or -std=gnu++0x0 " This is apparently something to do with the use of the { } parentheses in the macro definition: #define G_PRIVATE_INIT(notify) { NULL, (notify), { NULL, NULL } }
I think that G_PRIVATE_INIT should be protected inside something like #ifndef __cplusplus at least until c++11 implementations become mainstream. Because initializer-lists aren't part of c++03, the code below won't compile with a compiler that supports a c++ standard < c++11: GPrivate something = G_PRIVATE_INIT (some_func); You either have to do: GPrivate something; g_private_init (&something, &some_func); Or provide a c++ constructor for GPrivate, which is not an option for a C compatible API.
> g_private_init (&something, &some_func); Well, if we had that then we could just avoid using G_PRIVATE_INIT() and avoid the g++ warning. We could add documetnation to G_PRIVATE_INIT() recommending its use for people who hit this problem. Note that other threadish structs have such functions already: http://developer.gnome.org/glib/2.31/glib-Threads.html#g-mutex-init
The difference is that these functions only exist for the purpose of initialising a GMutex that is part of a structure. It is never appropriate to have a GPrivate anywhere except in static context -- and then a static initialiser should be sufficient. Is the specific problem that g++ can't handle the { NULL, NULL } part of the initialiser?
(In reply to comment #3) > It is never appropriate to have a GPrivate anywhere except in static context -- > and then a static initialiser should be sufficient. How strict is that? Is it OK to have a GPrivate C++ member variable in a Glib::Private class that is only ever used statically: class Private { private GPrivate goject_; } static Private private; That's what we are doing now, at least in our own code: http://git.gnome.org/browse/glibmm/tree/glib/glibmm/dispatcher.cc#n140 though we have not documented that Private class at all. Note that I don't use this code personally.
I begin to understand your issue.... How do you know what the destroy notify should be? It seems like this might be a usecase for templates on the C++ side? In any case, the ABI of the structure is very clearly public now -- or at least two facts about it: 1) zero-initialisation is appropriate 2) the destroynotify is the second pointer in the struct Using this information, you could probably just fill it in yourself... I'd not normally suggest that for 'regular' programmers, but since this is a rather special case, maybe it's not so bad. Did you have 'class Private' before that used to wrap a GPrivate* and now you're moving that to wrapping a GPrivate directly? How are you dealing with the ABI issues on the C++ side?
(In reply to comment #5) > Did you have 'class Private' before that used to wrap a GPrivate* and now > you're moving that to wrapping a GPrivate directly? How are you dealing with > the ABI issues on the C++ side? We entirely deprecated the old code that used gthread.h's API, and we added a new API (inside a new Glib::Threads namespace). So now we have a chance to do it properly.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/479.