[sldev] Plugin system - first code drop
soft at softnoel.org
Tue Feb 27 06:35:14 PST 2007
On Tue, February 27, 2007 1:19 am, Tim Shephard wrote:
>> You have three main concerns when exposing C++ classes in a shared
> Yes, your summary is great. Another problem is heap management, which
> I don't think is done the same way over all three platforms either.
> For all those reasons, and probably more, exposing classes over DLLs
> seems a tad risky.
Heap management is a problem whether you use C++ or C, if you mean the
potential problem of allocating on one side and freeing on the other, or
holding dangling pointers after a library unloads and its heap(s) are
destroyed. We should try to follow the LL coding standard's suggestion of
keeping handles rather than pointers as much as possible to avoid this.
Or did you mean something else?
>> > I included a win32 proof of concept for exposing classes across DLLs
>> > in a recent attachment on a previous email, so they could start with
>> > that.
>> The LLJacks in the LLJackBundle are already C++ classes exposed across.
>> It's working via dylibs right now, but as soon as AMD gets me going with
>> the Windows VPN, I'll show it working there as well. Or I'll suffer
>> humiliating defeat after being so cock-sure about it!
> Hmmm.. To be honest, I missed that. I probably wouldn't have gone in
> that direction because it seems a bit novel, but I admire your
Going from that to a COM-style struct of pointers would be little work,
just a little bit annoying. The calling convention doesn't change, only
the class declaration and function prototypes. Basically:
class LLJackFoo : public LLJack
struct LLJackFoo : public LLJack
FooFunc = LLJackFoo_FooFunc;
BarFunc = LLJackFoo_BarFunc;
You'd still call both with:
void SomeFunc( LLJackFoo *jf )
Of course, they also lose the "this" pointer, but we're not storing data
in the LLJacks.
More information about the SLDev