Re: Reference to a C++ object in GTK+ callbacks

On Wed, 2005-12-14 at 20:47 +0000, Chris Vine wrote:
On Wednesday 14 December 2005 20:38, Wallace Owen wrote:

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

Static member functions happen to work with g++.  They may not work with other 

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]