[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: tolua survey
- From: "mnicolet" <mnicolet@...>
- Date: Wed, 27 Nov 2002 15:46:50 -0300
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <firstname.lastname@example.org>
To: "Multiple recipients of list" <email@example.com>
Sent: Monday, November 25, 2002 2:19 PM
Subject: tolua survey
> We're trying to decide the future of tolua and we'd like to hear your
> If you use tolua (or something else) to automatically bind C or C++ code
> please fill in the brief survey below and send it directly to us at
> firstname.lastname@example.org .
> Thanks for your time.
> --lhf and celes
> * Do you use tolua? If not, do you use any other wrapper?
No. I created my own wrapper ( luapi ). But it´s not a true wrapper,
it´s a stub
library to provide for repetitive ´standard lua/C code´.
> * Do you use tolua for C or C++?
> * What features do you miss in tolua?
I decided not to try tolua because ´two file maintenance´, and lack of
( see ahead )
. My application code is frequently changed. Also, at first sigth, it
seems generating lots of code. .
Is this rigth ?
> * How could tolua be improved?
Celes just said that some comments are recognized ( even if a pkg still
needed ... but nearly
empty ). So, the ´two file´ question is half answered.
The remaining is an application design issue: are we coding lua bindings
into every application
module ? or are we confining the bindings to some ´special services´
Because of some config language independence, I am using the second
model: as far as I
can, the usage ( the service or functionality ) of the
configuration/extension language is
as confined as possible, having standard C functions which
´transparently´ returns the
´service´ results to the main environment. In other words, most
application modules are not
so much concerned with what exactly is going behind scenes. Of course,
there is not a
full functional independence: expected services are more or less coupled
to extension language
features, but at least we can recognize some ´access points´.
Partially, I prefer this model because some uncertainties: recently, I
posted some questions
( nobody answered ), by example, how to tigth control the gc. For a
the gc performance degradation is not an issue, while the total memory
Despite all the previous junk, I just revisited tolua docs.
Some ´extra conditional compiling´ would be neccesary, by example:
tolua has the pretty ´@´ ´token´ ( I don´t know what it´s exactly in
semantic terms )
to rename host objects. But currenttly, its use _requires_ a pkg hand
written, because there
is no way to fake the C compiler. Also, I see that some C++ keywords
must not appear
( ´public´ ) etc.
It seems to me that what is needed is a sort of specialist ´sed´, a tool
that reads a C/C++ header
a) some #ifdef directives
type cfunca( int, int, int a = 5 ) @ Coverloadedf
type cfuncb( char * ) @ Coverloadedf
type cfunca( int, int, int )
May be also required some extra trickery. Some preprocessors don´t
ignore the FALSE ifdef region. By example Watcom 10.6 generates an error
on this construct
#define BADSTR "badstring // note the absent closing quote
even if TOLUA is not defined, the pre parses the #define BADSTR line,
and claims that a
\ continuation char is absent, and worse, it thinks that all remaining
text is part of the
offending string, not seeing the endif etc
May be other preprocs do this way with other consttructs so may be (
compile time option ? )
the ´toluased´ tool needs to recognize thigs like
///(tolua) type .... etc
the ///(tolua) token would be neccesary to start a comment from the
preproc point of view, but
to inform the ´ssed´ that this is not really a comment from the tolua
b) some special block and line comments ( more than Celes reported )
.... // _tolua_line_include
... // _tolua_line_exclude
Having this tool ( which also a makefile could invoke ) one could devise the
pkg to $#include
an automatically generated file ...
I think about a distinct tool because it seems more easy to textually
´parse´ a file ´sed style´
ignoring the saved lines semantics and sintax than to do all af them at once
( the line ´directives´
are cumbersome ... )
Also, another good reason is customization: when compiling the tool, one
not only the ´special comments´ but, more important, the special constructs
fake the preproc ( the ´///(tolua)´ example ) but allowing true comments
I don´t even tried tolua, because while using 3.2, I was excessively newbie;
4.0, tolua was not ported to that version; then I find more understandable
the userdata logic of 5.0a, and married with.
> (end of survey)