[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: "Official" binding library
- From: Dimiter 'malkia' Stanev <malkia@...>
- Date: Mon, 05 Dec 2011 10:08:43 -0800
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.