RE: Sub lib compatibility with g++

["John (Eljay) Love-Jensen" <eljay at adobe dot com>]

Hi Kumar,

> Do you think this will work out ?

It can work.  It won't be fun.

> One other aspect I am concerned about is that with the above, myprog will eventually make use of both the gcc C++ runtime and the Sun C++ runtime (via the two MODULES A and B which respectively call into libs libA.so and libB.so).  Do you see any issues with that ?

The key issue is making sure that symbols are properly bound, such that the Sun C++ only binds to Sun C++ symbols by the loader, and GCC C++ only binds to GCC C++ symbols by the loader.

Another solution is to use separate processes, and then communicate to the Sun C++ "slave" process (assuming that's the one you'd make slave) through RPC or IPC or a listening socket.  That makes for a very clean demarcation between the GCC C++ process and the Sun C++ process.

> Also - do you know of any good examples and/or web resources that demonstrate how the "thunking" libs. should be created and provide more info. on the details ?

No, I'm not sure.

I learned it by working with Netwise RPC technology, before Microsoft acquired them.

Another good example of providing an opaque C interface to an object-oriented implementation is Apple's Carbon.  X11 is also a good example of object-oriented design, implemented in C (which could have been written in C++ -- maybe it is in some implementations).

If you only have one top level class to expose, say SunFoo...

class SunFoo
{
public:
    SunFoo();
    ~SunFoo();
    void DoSomething();
    void OtherSomething(std::string const&);
};

...you're thunking C interface will have to provide...

Initialize();
Terminate();
int ExceptionOccurred();
typedef struct OpaqueSunFoo* SunFoo_t;
SunFoo_t SunFooConstruct();
void SunFooDestruct(SunFoo_t);
void SunFooDoSomething(SunFoo_t);
void SunFooOtherSomething(SunFoo_t, char const*);

You'll need to have a "cookie" that represents a SunFoo on the GCC side.  Something like "typedef struct OpaqueSunFoo* SunFoo_t" can work well.

You'll need to "revive" all C-style parms into the SunFoo's C++ object parms.

You'll need to carefully manage memory allocation so the right side of the fence has ownership & responsibility to delete/free things.

You'll need to catch all exceptions and have some facility to query if an exception occurred.

If your Sun C++ has lots and lots of objects and methods that you want to expose... then that can be a considerable (and very unpleasant) challenge.

HTH,
--Eljay