3

I have a nested class in C++ that I want C code to be able to use. Because it is nested I cannot forward declare it to C, so instead we have code like this in a shared header file:

#ifdef __cplusplus
class Mgr {
public:
    class Obj {
        public:
        int x;
    };
};

typedef Mgr::Obj * PObj;
#else

typedef void* PObj;

#endif

This results in C and C++ each seeing a different definitions of PObj which I fear violates the one definition rule. However it is "just" a pointer, so I'm not sure if this can go wrong or not.

C does nothing with the pointer besides pass it along to C++ functions which are wrappers for methods. For instance we'll have this in the combined header:

#ifdef __cplusplus
extern "C" {
#endif
int obj_GetX(PObj pObj);

#ifdef __cplusplus
}
#endif /* __cplusplus */

With this as the implementation in the C++ file:

int obj_GetX(PObj pObj) {
    return pObj->x;
}

So:

  1. Is this really a problem?
  2. If so, what is the best way to share this pointer between C and C++
gil_bz
  • 478
  • 1
  • 5
  • 16
  • what do you need the `PObj` type for in C++? To me, it looks like something you'd never need in C++, and only in C. If you can make it that way, you can omit the C++ typedef, and never have conflicting types. – Marcus Müller Nov 09 '21 at 10:36
  • 4
    Well, C code can't directly create an instance of a nested class either, because the class definition is a diagnosable error in C. The best you can do is for `Mgr::Obj` to be seen as an opaque pointer in C and a `void *` is as good as any. To do almost anything with such a pointer (e.g. access or modify the object's members) other than comparing it with other such pointers your C code would need to pass that `void *` back to C++ code. Anything C code tries to do to the actual object's members directly (without help of appropriate functions written in C++) would cause undefined behaviour. – Peter Nov 09 '21 at 10:37
  • @Peter I added an explanation to what C does to the question. It only passes it along to wrapper functions for C++ methods. – gil_bz Nov 09 '21 at 12:00

1 Answers1

1

It's not a problem per-se, but you might violate the strict aliasing rule if and when you cast that void * back to Mgr::Obj * in your C++ code.

There's no good solution to this - it is (to me) a glaring omission in the standard. The best you can do is to compile any code which does such casts with the -fno-strict-aliasing flag. I do this extensively and have never had a problem performing casts in this manner.

Paul Sanders
  • 24,133
  • 4
  • 26
  • 48
  • I added usage example in the question, but I don't understand the strict aliasing problem, can you please explain? Note that the C++ code does not cast, C and C++ both see the type they understand in the function signature, so no need to cast. – gil_bz Nov 09 '21 at 11:59
  • 1
    Ah, I see, that's a bit sneaky. It's probably OK but I'm not sure if there might be a problem pulling the wool over the compiler's eyes like that. I would compile any C++ methods which you pass `PObj` to from C with `-fno-strict-aliasing` set, just in case. – Paul Sanders Nov 09 '21 at 12:02