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

[Wallace Owen <wallace owen L-3com com>]

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