[Qt-interest] QtScript conceptual questions
Kent Hansen
khansen at trolltech.com
Thu Jan 15 18:40:13 CET 2009
Hi Sean,
Sean M. Pappalardo wrote:
> Hello again.
>
> I have a few high-level questions about QtScript since it seems my
> understanding is seriously flawed:
>
> 1) Does one need to evaluate() an entire script file before calling
> individual functions contained within? (If not, would it hurt to do so?
> The point being to report syntax errors at the start of the program
> instead of at call time.)
>
evaluate() returns a SyntaxError object if there is a syntax error in
the script; you can get a string representation by calling toString() on
it, or access the properties of the object individually (e.g.
lineNumber, message).
If there _is_ a syntax error in the script, then no part of the script
is actually going to get evaluated (the only exception to this rule are
statements like "0 = 0" and "++0", which will throw a syntax error when
(if) that statement is actually reached during evaluation).
> 2) When one does QScriptValue slot = execute(functionname); what's
> actually happening? Are we making a self-contained object that is the
> function? Or simply referencing its instance in the ScriptEngine?
>
What does execute(functionname) do?
If you mean something like
QScriptValue fun = engine.evaluate("function foo() { return 123; }; foo");
Then yes, the C++ variable "fun" will now hold a reference to the script
function "foo".
"fun.call()" in C++ will achieve the same as doing "foo()" in a script.
> 3) When one then does qScriptConnect(object, SIGNAL(signalName()),
> QScriptValue(), slot); what's actually happening here? Are we connecting
> the signal to a self-contained object?
>
There's a magic C++ object behind the scenes that connects to the
signal. When the signal is received, the C++ arguments are converted to
script values and the function you passed as the last argument to
qScriptConnect() is called with the converted arguments.
> 4) What implications does all this have for multi-threaded code?
> Especially considering
> http://doc.trolltech.com/4.4/qtscript.html#controlling-qobject-ownership
>
See my latest reply in the "QtScript segfault on C++ signal
(dis)connection/firing" thread. Object ownership doesn't matter here,
thread affinity does.
> 5) What's the best way to protect against one thread evaluate()ing some
> function and a connected signal in another thread evaluate()ing another?
>
Again, see my previous reply. Because of the way signal handling works,
you'd have to not only synchronize the explicit calls to QtScript
functions, but also your signal emissions -- which would be a rather
unworkable solution. Use queued connections, use
QMetaObject::invokeMethod(), have threads communicate through events;
see e.g.
http://doc.trolltech.com/4.4/eventsandfilters.html#sending-events. In
this way you rely on the (thread-safe!) primitives provided by Qt to
serialize access to the script engine.
Regards,
Kent
More information about the Qt-interest-old
mailing list