How to turn an ANSI C struct into a C++ class, but keep it ANSI C friendly?

Question

A frame read out from external device is stored in shared memory (in a struct), to be used both by main (C++) application, and an ANSI C library.

For reasons a bit too broad to explain here the library must remain pure ANSI C, and must retain access to the structure in its "pure ANSI C" form. But the main application uses the data in a lot of places, and it's a nuisance to do this the "ANSI C" way, treating it as a dumb data container. It would be much nicer if it was a class - if I could add constructors, copy constructor, comparison operators, a neater 'is valid' method (currently checked as absence of a magic number in one of the struct fields), generally a lot of stuff that a C++ class can do, but an ANSI C struct can't. Except if I replace the struct with the class in the shared memory, it will break compatibility with the library.

What's a neat way to achieve this? Create a class that inherits from the struct? Inheritance through composition? A separate class with a set of conversion methods? Something else I didn't think about? Some transparent way to keep the data visible to C unchanged, but enhanced with class features for C++?

Note: both C++ and C operate on the same instance of the structure. Main app reads out the frame out of the device, writes to the structure in shared memory, then calls the library functions to do their magic on the frame (possibly, but not necessarily modifying it; business logic), then performs own operations on it (display, logging, re-broadcasting on other media etc.

I have full control over the C++ code, but C code is mostly out of my control; I can create a local copy of the structure, if that's beneficial, but my copy and the 'business logic instance' should remain in sync, or at least be synced before and after each library function call (operation under my control, but timing dictated by system requirements.)

edit: some extra details, as requested:

• the "business logic" is implemented in the C library, customized C code generated by an external application (for PC) from input from user (graphical interface for drafting the logic; think "block diagram"), varies per device (many users, even more devices). The device requires cross-compiling; only an ANSI C cross-compiler is available in a form that can be easily bundled with the PC application; C++ cross-compiler is available only on the system developer's (my) PCs ; its installation process and license make it impossible to bundle with the (sold) generator app.

• the library and the C++ application on the device use shared memory as storage of about all input and output data, for two reasons:

  • primarily because the volume and variety of that data would make it extremely difficult to provide it as parameters in function calls (over 20 wildly varying external systems the device can cooperate with, each with own communication protocol, each providing inputs and/or accepting outputs which may be utilized in business logic). C++ app handles all communication and converts the data back and forth between the various interfaces and an "easily digestible" data format stored in the shared memory for consumption by the library as required (by the particular instance of business logic).
  • But there are other applications running on the device - a WWW server, a debug app, etc - which can peer into the shared memory too, to display current state, allow real-time parameter tweaks etc. While such "centralized storage"/"superglobal" may be considered an anti-pattern, considering the wild variety of interactions between the systems (internal, and external, where the C++ serves as a central hub for connecting them) and makes for a much clearer structure than what kind of byzantine web would arise if I tried to connect every data provider with every data consumer directly.
• The main app handles synchronization (timing, locking) reads from shared memory for all interfaces where it matters; others can just peer into the shared memory and pick what they need whenever they want (read-only); resulting race condition errors will result in a perfectly acceptable momentary glitch that will be corrected come next 'tick'. All writes are synchronized.
• because the C library is the primary, most important consumer and provider for the shared memory, the structure in shared memory must remain C compatible.

Answer 1

Create a class that is derived from the C-struct but make sure that the memory layout stays untouched, i.e. do not use virtual methods (these would add a vtable) or add member variables. In C++11 terms this would be called a standard-layout class. For more information see here:

What are Aggregates and PODs and how/why are they special?

Obeying this rule you can safely cast between the C struct and C++ class and use the appropriate member functions.

Note: Regarding allocating the data structure you need to use the same set of functions for release as for allocation, i.e. if it has been allocated using malloc(), it must be released using free() and if it has been allocated using new it must be released using delete. Therefore, if you want to allocate objects both from within C and C++ code, you are limited to malloc/free since new/delete is not available from within C.

Answer 2

If you somehow subclass this, the base structure would need a vtable. Can you change the struct to include these elements, and then cast it to/from the class/struct. You'd need to use reinterpret_cast<>().

However that is a terrible idea. Please do not do it.

Instead, implement your business logic in a class, that contains the struct. This way you won't need to support marshalling the structure between the two codebases, you can keep one copy of the struct.

However remember to mark the struct as volatile, if it needs to be altered by any form of background thread that the C++ code is not aware of.

Answer 3

simple, move your c struct to c++ PIMPL

// A.h
class A
{
 //...
private:
 struct impl;
 static std::unique_ptr<impl> p_impl;
}

// A.cpp
std::unique_ptr<A::impl>  A::p_impl;

struct A::impl
{
  // c code here
}

Answer 4

My understanding is that the C++ managing code allocates a block of shared memory, and the C and C++ code coordinate what type of information will be written where. The C++ manager periodically examines locations in memory, knowing what type of data it expects to find. I imagine then that the C++ code has a table of void* pointers to your_c_struct* pointers to examine. In the former case, these can always be converted as necessary via reinterpret_cast<your_c_struct*>(void_ptr). So, I'll assume that the C++ code has a table of pointers to C structs in shared memory. In that case I think a solution is to create a pseudo-RAII class, which can either point to un-owned locations in shared memory or own and allocate/deallocate memory on the heap. This would look something like:

class Wrapper {
public:
    Wrapper() : owned(true), data(new your_c_struct{}) {}
    Wrapper(your_c_struct* _data) : owned(false), data(_data) {}
    ~Wrapper() {
        if (owned)
            delete data;
    }

    // copy constructors
    // overloaded comparison operators

private:
    bool owned;
    your_c_struct* data;
};

There are two main ways to construct this class: either making a new object on the heap or passing it a pointer to shared memory that it does not own. I've used this technique for the GSL library successfully, where the equivalent of C structs in shared memory are C structs allocated within and returned by GSL numerical algorithms. I went a further step of making the second constructor provide and providing a named constructor Wrapper Wrapper::SoftWrap(your_c_struct* _data).