On Wed, 2005-12-14 at 20:47 +0000, Chris Vine wrote: > On Wednesday 14 December 2005 20:38, Wallace Owen wrote: > > [snip] > Your version isn't portable either. GTK+ callbacks required C linkage, so to > be portable your code should provide C linkage, and static member functions > cannot have C linkage. This means that to be portable the callback has to be > declared extern "C" in file scope (and if it needs access to the class's > internals, needs to be declared a friend in the class definition). > > Paragraph 7.5.1 of the standard says this: > > "All function types, function names, and variable names have a language > linkage. The default language linkage of all function types, function names, > and variable names is C++ language linkage. Two function types with > different language linkages are distinct types even if they are otherwise > identical." > > Static member functions happen to work with g++. They may not work with > other > compilers.
Very true. We've been getting away with it for so long that I'd forgotten that bit. I've never been bit by it (unlike coercing invocation of non-static member functions as callbacks and slipping it's 'this' pointer in as the first param). The only situation I can think of where language linkage is a problem with gcc/g++ is where a C-compiled function tries to invoke a C++- compiled function in a separate compilation unit and the linker complains that the function is unresolved because the C++ function's name has been mangled. // Wally _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
