From: Michael O'Connor <moconnor59@ya...> - 2004-03-11 22:45:32
Julian Stecklina asked: I am interested what you need
that for. Could you please elaborate?
The C++ application I'm working on iterates over a set
of data and calls the interpreter to implement logic
and rules (written in Lisp) that apply to the data.
The Lisp code will be making callbacks to the
application to read various bits of data, and also to
return a result to the application for each dataset.
I'd like to write a single library module in the
application that handles things like translating C/C++
variables to / from cl_object instances (which will
need to be called for every argument and return-value
in each Lisp / C++ function call). Ideally the C++
code outside the library doesn't need to know anything
about Lisp variables (cl_object), they would just pass
ints, strings, etc. as usual to the library which
would perform the translation transparently.
However the callback funtion passed to
cl_def_c_function() has to uniquely identify the C
function that it's intending to call, and this is
where the problem occurs. I'm trying to write a
generic library routine that will behave as an
intermediate callback function to do the translation
etc., but this isn't possible without the library
routine storing some state data to help indicate the
actual callback function that needs to be called,
hence my original question.
--- Michael O'Connor <moconnor59@...> wrote:
> Quick question (I hope): does ECL support the idea
> "client callback data"? By this I mean a C void
> pointer (void *) or similar that can be used to
> / refer to context data in calls to the C/C++
> This pointer would probably be passed into the call
> cl_def_c_function() and would be returned to the
> application when Lisp calls the C function.
> I hope that makes sense.
> Do you Yahoo!?
> Yahoo! Search - Find what youre looking for faster
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
Michael O'Connor <moconnor59@...> writes:
> However the callback funtion passed to
> cl_def_c_function() has to uniquely identify the C
> function that it's intending to call, and this is
> where the problem occurs. I'm trying to write a
> generic library routine that will behave as an
> intermediate callback function to do the translation
> etc., but this isn't possible without the library
> routine storing some state data to help indicate the
> actual callback function that needs to be called,
> hence my original question.
Ok, clearly I am lost here. :)
Julian Stecklina Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
"I meant," said Iplsore bitterly, "what is there in=20
this world that makes living worthwhile?" Death=20
thought about it. "CATS," he said eventually, "CATS=20
ARE NICE." - Terry Pratchett, Sourcery