Re: Lua <-> C++ integration with "unused" stack slots

["Oliver Schmidt" <oschmidt_do_not_send_email_to_this_address@...>]

> But you generally should not use a C++ object to hold a Lua stack
> value. If you write something to wrap the usage, you futher promoted
> the abuse.

Why not? It works and reduces errors that could otherwise
occur if manually using lua_push.., lua_replace, etc.

The only danger is to use a LuaVar as an object member of a C++
object that is living on the heap.

This danger can be avoided by using runtime checks inside the 
LuaVar implemention (e.g. in the DEBUG=true version of the
program), that are not visible for the user of LuaVar objects.


> This should instead be:
> 
> > string f(map x, const char* str)
> > {
> >   string rslt;
> >   if (x.isTable()) {

Do you mean std::map? This does not have a isTable 
method.


> >        string y = f(x, argv[i])
> >        if (y) {
> >           ...
> >        }

Your example does something different. Here the
function f is forced to return a std::string. But what, if
one possible result could also be a Lua table?


> It is better to only use lua stack variable within one function, pass
> lua stack value between c functions are dangerous and result in
> difficult-to-maintain code.

I tried it and it worked and with runtime checks enabled (to prevent
usage of LuaVars without their corresponding Lua stack context) it
is also very easy to maintain and easy to find bugs.


> A program which contains only standard C++ class, and a program which
> contains lot's of lua private classes. What is more readable?

What do you mean with "lua private classes"? Do you mean something
like the class LuaVar? IMHO some C++ wrapper classes for easy
access to Lua objects could increase the readability. The user
then will only use LuaVar objects and some other classes and
never use the Lua C-API directly.

IMHO it depends on the prefered usage pattern and on the
project's goals and there is no general answer to this question
that fits all needs.

> You're introducing the Python way of embed, and that reduces the
> readibility of source code more than improvement.

So do you think the example code I gave is not easy to understand?

Best regards,
Oliver

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser