Trolltech Home | Qt4-preview-feedback Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt4-preview-feedback Archive, February 2007
QT4.3 Notification of Garbage Collection

Message 1 in thread

Hi,

I've recently been altering a QT4 application to provide a scripting
interface using the latest QT4.3 snapshot. This works well, but
required the addition of a number of wrapper classes for all the
various C++ objects that can be manipulated in script. The scripting
engine is efficient and there is no noticable speed penalty using
these wrappers.

However my conversion routines to/from QScriptValue objects malloc
blocks of memory and it is unclear when I can subsequently free these.
I assume the QScriptValue objects are garbaged collected by the
ScriptEngine when they fall out of scope, but there does not appear to
be any notification passed on that would prompt me to free the
associated memory block. Is there a general way to achieve this as the
memory leaks are a disaster?

Code snippet:

Q_DECLARE_METATYPE(QSMyObject*);

engine->globalObject().setProperty("access",
engine->globalObject().property("accessMyObject"));

QObject* QSAClassWrapper::accessMyObject(QSIdentifier* t)
{
    MyObject* data = AClass::LookupValue(t);
    return new QSMyObject(data);
}

Thanks in advance.

Regards,
Simon

To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 2 in thread

Simon Bourne wrote:
> Hi,
>
> I've recently been altering a QT4 application to provide a scripting
> interface using the latest QT4.3 snapshot. This works well, but
> required the addition of a number of wrapper classes for all the
> various C++ objects that can be manipulated in script. The scripting
> engine is efficient and there is no noticable speed penalty using
> these wrappers.
>
> However my conversion routines to/from QScriptValue objects malloc
> blocks of memory and it is unclear when I can subsequently free these.
> I assume the QScriptValue objects are garbaged collected by the
> ScriptEngine when they fall out of scope, but there does not appear to
> be any notification passed on that would prompt me to free the
> associated memory block. Is there a general way to achieve this as the
> memory leaks are a disaster?
Hi Simon,
Rather than creating wrapper objects, you can use the QScriptable class
to create a single prototype object that will be shared by all
"instances" of your QSMyObject* metatype. Unfortunately this is not well
documented yet, but an example has recently been added to the snapshots
(examples/script/defaultprototypes) which shows how one can do it. Code
snippets:

Q_DECLARE_METATYPE(QListWidgetItem*)

class ListWidgetItemPrototype : public QObject, public QScriptable
{
    Q_OBJECT
    Q_PROPERTY(QString text READ text WRITE setText)
public:
    QString text() const;
    void setText(const QString &text);
};

QString ListWidgetItemPrototype::text() const
{
    QListWidgetItem *item =
qscriptvalue_cast<QListWidgetItem*>(thisObject());
    if (item)
        return item->text();
    return QString();
}

void ListWidgetItemPrototype::setText(const QString &text)
{
    QListWidgetItem *item =
qscriptvalue_cast<QListWidgetItem*>(thisObject());
    if (item)
        item->setText(text);
}



Then you create and register the prototype:

ListWidgetItemPrototype lwiProto;
engine.setDefaultPrototype(qMetaTypeId<QListWidgetItem*>(),
engine.newQObject(&lwiProto));



Alternatively, you can create wrapper objects that will be deleted upon
GC, thanks to a new optional argument to QScriptEngine::newQObject()
that allows you to specify ownership (you'll probably see it in
tomorrow's snapshots). Your toScriptValue conversion function can then
look something like this:

QScriptValue toScriptValue(QScriptEngine *engine, MyClass* const &source)
{
    return engine->newQObject(new MyClassWrapper(source),
QScriptEngine::ScriptOwnership);
}

Good luck,
Kent


>
> Code snippet:
>
> Q_DECLARE_METATYPE(QSMyObject*);
>
> engine->globalObject().setProperty("access",
> engine->globalObject().property("accessMyObject"));
>
> QObject* QSAClassWrapper::accessMyObject(QSIdentifier* t)
> {
>    MyObject* data = AClass::LookupValue(t);
>    return new QSMyObject(data);
> }
>
> Thanks in advance.
>
> Regards,
> Simon
>
> To unsubscribe - send "unsubscribe" in the subject to
> qt4-preview-feedback-request@xxxxxxxxxxxxx
>

To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 3 in thread

Hi Kent, all

While we're on the topic of Garbage Collection...

I've been working on a Lua binding for my Qt-based app and am very 
interested to see the ECMAscript support for Qt4.3 since ECMAscript is 
obviously a lot cooler ;-)

I chose Lua because it is fasr and has a near-real-time incremental GC which 
is good for running in my real-time audio application (also good for 
games)... I'm wondering whether Kent (or other trolls) could give a little 
info on the requirements and design for the collector in the new Qt script 
engine? Should I expect equivalent or better performance than Lua's 
collector in the medium term? Are you guys intending for the scripting 
engine to be used for high performance soft real time apps like high 
frame-rate games, or is it just intended as a kind of application scripting 
engine like VBA?

Thanks!

Ross. 

To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx