lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Talking about that, I wish more libraries are like ZeroMQ - use C++ internally as much as they want, but expose "C" interface. In their case - they only expose the "C" one - they even have an additional C++ bindings library that re-exposes the C++ ones.

C is proven interface to work for system level work, because it's compatible across many compilers and run-time systems. C++ is nice that it embeds types and such, but it fails to encode them the same way on the binary level (would not even start mentioning the class layout and virtual inheritance low-level schemes).

On 12/5/2011 3:47 AM, Enrico Colombini wrote:
On 05/12/2011 12.32, steve donovan wrote:
That's the rub. I pity the poor bastards who have to bind to C++.

I, er, 'solved' the problem by going through C when calling C++ from
Lua, passing back an object identifier previously received from C++.

It could be slower (it wasn't in my simple case), but I prefer not to
keep C++ pointers on the Lua side unless I have no choice; I also try to
decouple the two sides from each other as much as possible.
I consider decoupling a very important factor in code robustness and I
think (generally speaking) that making C++ class members directly
accessible from Lua would be looking for trouble.

So I made C++ (actually, the C dispatcher) ony accessible from Lua
through a dedicated API, and did the same on the Lua side.