Re: luabind in different DLLs

On Friday, September 10, 2010, Dmitry K <[email protected]> wrote:
> Hi there!I'm working on a component system, where components may be added via DLLs.However I have some problems registering two different modules in different DLLs.Let me explain.
> I have a base class called ComponentFactory
> class ComponentFactory{	public:		virtual ~ComponentFactory(){}
> };
> (un-needed details omitted)This one defined in DLL lets call it Main.dllIts exported to Lua using luabind in the following way:
> module(lua)[
> 	class_<ComponentFactory>("ComponentFactory")];
> (I tried to define constructor as well via .def(constructor<>()) )
>
> When another component is added to the system, it inherited from the ComponentFactory and placed in different DLL. Example:I made a DummyComponent that looks like
>
> class DummyComponentFactory: public ComponentFactory{public:	DummyComponentFactory():mDummy(0){}
> 	void SetDummy(int d) { mDummy = d; }
> 	int GetDummy() const { return mDummy; }
> private:	int mDummy;
> };
> Which is exported to Lua using luabind as:
> luabind::module(lua)[	luabind::class_<DummyComponentFactory, ComponentFactory>("DummyComponentFactory")
> 	.def(luabind::constructor<>())	.def("get", &DummyComponentFactory::GetDummy)
> 	.def("set", &DummyComponentFactory::SetDummy)];
> Its compiled to a DLL called DummyComponent.dll and loaded by my Main.dll which calls a special functions to actually export the DummyComponentFactory to Lua.
> So to sum up: after the system is initialized I have both the base class and the inherited class exported to Lua using luabind.Now when I execute the following Lua code:cf = DummyComponentFactory()
> cf:set(10)I get an error:No matching overload found, candidates: void set(DummyComponentFactory&, int)Now I googled a lot and found some guy that had the same problem (luabind module split in different DLLs) but I cant find that topic right now >.>
> He said something about typeid and that each DLL keeps its own typeid (dont remember for sure).I need help with this since I have to export it like this.For the record: I'm using Lua5.1 with luabind0.9 (the luabind I compiled myself in Visual Studio 2010).
>
> Thanks a lot!
>

You are probably correct as to why the error is happening. There are
no guarantees that type_info is the same in a dll as in another
executable yet this works with some implementations, also the type
name is not guaranteed to be unique even in the same executable. Boost
Any ran into this problem and there is a bug entry and a dissucion on
it's mailing list. IIRC 'Any' tries the type info and then tries a
string comparison on the name in an effort to compare two types. There
was a propsal to use a typeid based on boost python yet I am unsure of
the outcome.

So if Luabind tries using the default info for example in a class type
comparison or dynamic cast then you could see problems.

Liam

------------------------------------------------------------------------------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev