What kinds of C++ functions can be placed in a C function pointer?

Question

I have a C library that uses a struct of function pointers for callbacks. The callbacks will be called from C code.

extern "C" {
typedef struct callbacks_t {
    void (*foo) (const char*);
    int  (*bar) (int);  
} callbacks_t;
}// extern C

What kinds of C++ functions can I safely place in those function pointers to be called from the C library? Static member functions? Fully specified template functions? Non-capturing Lambdas?

g++ seemingly lets me use all of the above, but I question the safety when different calling conventions and language bindings are used for C and C++ functions.

Answer 1

I have a C library that uses a struct of function pointers for callbacks. The callbacks will be called from C code.

A C library only understands C. So you can only pass back things that are explicitly supported and understood by C.

Since there is no definition of calling conventions for any function types in C++ you can not explicitly pass back C++ functions. You can only pass back C function (those explicitly declared with extern "C") and guarantee that they are compatible.

Like all undefined behavior this may seem to work (like passing back normal C++ functions or static members). But like all undefined behavior it's allowed to work. You just can't guarantee that it's actually correct or portable.

extern "C" {
    typedef struct callbacks_t {
        void (*foo) (const char*);
        int  (*bar) (int);  
    } callbacks_t;

    // Any functions you define in here.
    // You can set as value to foo and bar.

}// extern C

What kinds of C++ functions can I safely place in those function pointers to be called from the C library?

Static member functions?

No. But this happens to work on a lot of platforms. This is a common bug and will bite people on some platforms.

Fully specified template functions?

No.

Non-capturing Lambdas?

No.

g++ seemingly lets me use all of the above,

Yes. But it is assuming that you are passing to objects that are built with the C++ compiler (which would be legal). As C++ code will use the correct calling convention. The problem is when you pass these things to a C library (pthreads springs to mind).

Answer 2

In general, unless you use cast, you should trust g++.

While it is true that none of the function types you mention can be exported to use from within C, this is not what you're asking. You are asking about what functions you can pass as a function pointer.

To answer what you can pass, I think it is more constructive to understand what you cannot pass. You cannot pass anything that requires additional arguments not explicitly stated in the arguments list.

So, no non-static methods. They need an implicit "this". C will not know to pass it. Then again, the compiler won't let you.

No capturing lambdas. They require an implicit argument with the actual lambda body.

What you can pass are function pointers that require no implicit context. As a point of fact, you went ahead and listed them:

• Function pointer. It doesn't matter whether it is a standard function or a template, so long as the template is fully resolved. This is not a problem. Any syntax you write that results in a function pointer will automatically fully resolve the template.
• Non capturing lambdas. This is a special work-around introduced by C++11 when it introduced lambdas. Since it is possible to do so, the compiler does the explicit conversion required to make it happen.
• Static methods. Since they are static, they do not get passed an implicit this, so they are okay.

The last one bears expanding on. Many C callback mechanisms get a function pointer and a void* opaq. The following is a standard and fairly safe of using them with a C++ class:

class Something {
  void callback() {
    // Body goes here
  }

  static void exported_callback(void *opaq) {
    static_cast<Something*>(opaq)->callback();
  }
}

And then do:

Something something;

register_callback(Something::exported_callback, &something);

Edited to add: The only reason this works is because the C++ calling convention and the C calling convention are identical when no implicit arguments are passed. There is a difference in name mangling, but it is not relevant when you pass a function pointer, as the sole purpose of name mangling is to allow the linker to find the correct function's address.

Had you tried that trick with a callback expecting, e.g., an stdcall or pascal calling convention, this scheme would fall flat on its face.

This, however, is not unique to static methods, lambdas and template functions. Even a standard function would fail under those circumstances.

Sadly, when you define a function pointer to an stdcall type, gcc ignores you:

#define stdcall __attribute__((stdcall))
typedef stdcall void (*callback_type)(void *);

results in:

test.cpp:2:45: warning: ‘stdcall’ attribute ignored [-Wattributes]
 typedef stdcall void (*callback_type)(void *);