Calling a C++ Shared Lib within a C program...how to manage?

Question

hi all,

i'd like to write a wrapper for a C++ framework. this framework is kinda buggy and not really nice and in C++. so i'd like to be able to call their methods from outside (via good old C file) of their framework by using just one shared lib. this sounds like the need for a wrapper that encapsulates the wanted framework methods for usage with C instead of C++.

So far so good.... here is what i already did:

interface aldebaran.h (this is in my include folder, the ultrasound methods should be called from outside of the framework):

#ifndef _ALDEBARAN_H
#define _ALDEBARAN_H

#ifdef __cplusplus
 extern "C" {
#endif

void subscribe_ultrasound();
void unsubscribe_ultrasound();
float read_ultrasound();

#ifdef __cplusplus
}
#endif

#endif

now the wrapper:

cpp file aldebaran.cpp:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "aldebaran.h"
#include "alproxy.h"
#include "../../include/aldebaran.h"

/*
 * Ultrasound defines
 */
#define ULTRASOUND_RESERVATION_MAGIC  "magic_foobar"

#define ULTRASOUND_POLL_TIME          250
#define ULTRASOUND_READ_ATTEMPTS      50
#define ULTRASOUND_SLEEP_TIME         20

using namespace std;
using namespace AL;

/*
 * Framework proxies
 */
ALPtr<ALProxy> al_tts;
ALPtr<ALProxy> al_led;
ALPtr<ALProxy> al_motion;
ALPtr<ALProxy> al_mem;
ALPtr<ALProxy> al_us;
ALPtr<ALProxy> al_cam;
ALPtr<ALProxy> al_dcm;

/*
 * Constructor
 */
Aldebaran::Aldebaran(ALPtr<ALBroker> pBroker, std::string pName): ALModule(pBroker, pName)
{
    try {
        al_tts    = this->getParentBroker()->getProxy("ALTextToSpeech");
        al_led    = this->getParentBroker()->getProxy("ALLeds");
        al_motion = this->getParentBroker()->getProxy("ALMotion");

        al_mem    = this->getParentBroker()->getProxy("ALMemory");
        al_us     = this->getParentBroker()->getProxy("ALUltraSound");
        al_cam    = this->getParentBroker()->getProxy("NaoCam");
        al_dcm    = this->getParentBroker()->getProxy("DCM");
    }catch(ALError& err){
        std::cout << "XXX: ERROR: " << err.toString() << std::endl;
        return 1;
    }

    printf("XXX: module aldebaran initiated\n");
    fflush(0);
}

/*
 * Destructor
 */
Aldebaran::~Aldebaran()
{
    printf("XXX: module aldebaran destructed\n");
    fflush(0);
}

/*
 * Subscribe to ultrasound module
 */
void subscribe_ultrasound()
{
    ALValue param;

    param.arrayPush(ULTRASOUND_POLL_TIME);
    al_us->callVoid("subscribe", string(ULTRASOUND_RESERVATION_MAGIC), param);

    printf("XXX: ultrasound subscribed: %s\n", ULTRASOUND_RESERVATION_MAGIC);
    fflush(0);
}

/*
 * Unsubscribe to ultrasound module
 */
void unsubscribe_ultrasound()
{
    al_us->callVoid("unsubscribe", string(ULTRASOUND_RESERVATION_MAGIC));

    printf("XXX: ultrasound unsubscribed: %s\n", ULTRASOUND_RESERVATION_MAGIC);
    fflush(0);
}

/*
 * Read from ultrasound module
 */
float read_ultrasound()
{
    int i;
    float val1, val2;
    float val_sum;
    ALValue distance;

    val_sum = .0f;

    for(i = 0; i < ULTRASOUND_READ_ATTEMPTS; ++i){
        SleepMs(ULTRASOUND_SLEEP_TIME);

        distance = al_mem->call<ALValue>("getData", string("extractors/alultrasound/distances"));
        sscanf(distance.toString(AL::VerbosityMini).c_str(),"[%f, %f, \"object\"]", &val1, &val2);

        val_sum += val1;
    }

    return val_sum / (1.f * ULTRASOUND_READ_ATTEMPTS);
}

definition file for aldebaran.cpp:

#ifndef ALDEBARAN_API_H
#define ALDEBARAN_API_H

#include <string>

#include "al_starter.h"
#include "alptr.h"

using namespace AL;

class Aldebaran : public AL::ALModule
{
    public:
        Aldebaran(ALPtr<ALBroker> pBroker, std::string pName);

        virtual ~Aldebaran();

        std::string version(){ return ALTOOLS_VERSION( ALDEBARAN ); };

        bool innerTest(){ return true; };
};

#endif

So this should be a simple example for my wrapper and it compiles fine to libaldebaran.so.

now my test program in C:

... now i'd like to call the interface aldebaran.h methods from a simple c file like this:

#include <stdio.h>

/*
 * Begin your includes here...
 */

#include "../include/aldebaran.h"

/*
 * End your includes here...
 */

#define TEST_OKAY    1
#define TEST_FAILED  0

#define TEST_NAME "test_libaldebaran"

unsigned int count_all = 0;
unsigned int count_ok  = 0;

const char *__test_print(int x)
{
    count_all++;

    if(x == 1){
        count_ok++;

        return "ok";
    }

    return "failed"; 
}

/*
 * Begin tests here...
 */

int test_subscribe_ultrasound()
{
    subscribe_ultrasound();

    return TEST_OKAY;
}

int test_unsubscribe_ultrasound()
{
    unsubscribe_ultrasound();

    return TEST_OKAY;
}

int test_read_ultrasound()
{
    float i;

    i = read_ultrasound();

    return (i > .0f ? TEST_OKAY : TEST_FAILED);
}

/*
 * Execute tests here...
 */

int main(int argc, char **argv)
{
    printf("running test: %s\n\n", TEST_NAME);

    printf("test_subscribe_ultrasound:    \t %s\n", __test_print(test_subscribe_ultrasound()));
    printf("test_read_ultrasound:         \t %s\n", __test_print(test_read_ultrasound()));
    printf("test_unsubscribe_ultrasound:  \t %s\n", __test_print(test_unsubscribe_ultrasound()));

    printf("test finished: %s has %u / %u tests passed\n\n", TEST_NAME, count_ok, count_all);

    return (count_all - count_ok);
}

how can i manage to call these methods? i mean within my C file i have no possibility to create such an object-instance (that generated all the needed ALProxies), have i?

help would be really appreciated... thx

Answer 1

You said yourself to create a C wrapper API around an OO framework.

This means you don't need any objects passing the wrapper API (as it appears from the decribed header). It seems all objects needed are created/destructed behind the wrapper API, out of view of your test program.

The first seems the case. You don't need objects to test your wrapper API. In the end, all objects are bytes (in memory) that are accessed through a fixed set of functions. It doesn't matter much whether the functions are written as member-functions (C++) or as plain C functions, as long as they obey the intended semantics of your objects.

Answer 2

You might want to take a slightly different approach. Consider something like this for your C interface:

#ifdef __cplusplus
extern "C" {
#endif

struct UltrasoundHandle;

UltrasoundHandle* ultrasound_Create();
void ultrasound_Destroy(UltrasoundHandle *self):
void ultrasound_Subscribe(UltrasoundHandle *self);
void ultrasound_Unsubscribe(UltrasoundHandle *self);
float ultrasound_Read(UltrasoundHandle *self);

#ifdef __cplusplus
}
#endif

The UltrasoundHandle structure is purposefully opaque so that you can define it in the implementation to be whatever you want it to be. The other modification that I made was to add explicit creation and destruction methods akin to the constructor and destructor. The implementation would look something like:

extern "C" {

struct UltrasoundHandle {
    UltrasoundHandle() {
        // do per instance initializations here
    }
    ~UltrasoundHandle() {
        // do per instance cleanup here
    }
    void subscribe() {
    }
    void unsubscribe() {
    }
    float read() {
    }
};


static int HandleCounter = 0;


UltrasoundHandle* ultrasound_Create() {
    try {
        if (HandleCounter++ == 1) {
            // perform global initializations here
        }
        return new UltrasoundHandle;
    } catch (...)  {
        // log error
    }
    return NULL;
}

void ultrasound_Destroy(UltrasoundHandle *self) {
    try {
        delete self;
        if (--HandleCounter == 0) {
            // perform global teardown here
        }
    } catch (...) {
        // log error
    }
}

The key is to wrapping C++ interfaces for C is to expose the OO concepts through free functions where the caller explicitly passes the object pointer (this) to the function and to explicitly expose the constructor and destructor in the same manner. The wrapper code can be almost mechanically generated from there. The other key points are that you never let exceptions propagate outward and steer clear of global object instances. I'm not sure if the latter will cause you grief, but I would be concerned about construction/destruction ordering problems.

Answer 3

I'm not clear whether you're aware of this, but if you have C++ code to dynamically load into your program, then you should link your program with the C++ compiler and make your main function a C++ function too - even if it is as trivial as:

int main(int argc, char **argv)
{
    return(real_main_in_c(argc, argv));
}

The real_main_in_c() function is what you previously called main(); it has simply been renamed. This ensures that the C++ mechanisms for handling initialization of global and static variables, etc, are loaded and operational. The C++ startup code does more work than the C startup code. Dynamically loading C

This is only one (small) facet of the answer - but it is an important practical one.

Answer 4

thank you very much so far!!

as xtofl said.. i'd like to keep my interface as simple as possible (without another c++ object preferably):

#ifndef _ALDEBARAN_H
#define _ALDEBARAN_H

#ifdef __cplusplus
 extern "C" {
#endif

void subscribe_ultrasound();
void unsubscribe_ultrasound();
float read_ultrasound();

#ifdef __cplusplus
}
#endif

#endif

the problem hereby is that functions like *subscribe_ultrasound()* cannot be called without the instanciation of all the proxies... this is our precondition:

...
        al_tts    = this->getParentBroker()->getProxy("ALTextToSpeech");
        al_led    = this->getParentBroker()->getProxy("ALLeds");
        al_motion = this->getParentBroker()->getProxy("ALMotion");

        al_mem    = this->getParentBroker()->getProxy("ALMemory");
        al_us     = this->getParentBroker()->getProxy("ALUltraSound");
        al_cam    = this->getParentBroker()->getProxy("NaoCam");
        al_dcm    = this->getParentBroker()->getProxy("DCM");
...

if i don't have the code above called, all other will fail.

within their framework it is possible to "autoload" my libaldebaran.so via a python script like this call:

myModule = ALProxy("Aldebaran",  global_params.strRemoteIP, global_params.nRemotePort );

The framework log then says:

May 10 15:02:44 Hunter user.notice root: XXX: module aldebaran initiated
May 10 15:02:46 Hunter user.notice root: INFO: Registering module : 'Aldebaran'
May 10 15:02:46 Hunter user.notice root: ______ End of loading libraries ______

which is totally okay... it called the constructor of my module (so all other needed proxies got instanciated too).

but of course this instance does not belong to my C program...

maybe there is a possibility to share this to all other processes?

Answer 5

Keep things as simple as possible - but not simpler. I think you're trying to make it too simple here, wrap it all up but use the c++ compiler.

so, if you create your wrapper using the c++ compiler, you can instantiate the objects inside your subscribe function, release them all in the unsubscribe, all using static (or global) objects. The 3 functions you want to expose simple get wrapped with "extern C" and you have a C-style interface exposed to any caller, whilst still encapsulating C++ objects.

If you need another function to instantiate all the proxies, add one; alternatively if they don't already exist, create them so they'll always be created in the first call to subscribe.

Now, if you need the proxy objects on a per-instance basis (ie you have 2 callers who both want to subscribe, and need a unique proxy per caller), then you'll have to store the objects in a collection (I suggest a map), every call you make must then pass in a 'handle' or 'sessionid' that you use to extract the per-call objects from the map.