QSA-interest Archive, June 2006
variables assignment
Message 1 in thread
Then I assign one variable to another only QObject* copies, not real value,
why?
It's a bug or a feature?
For exmaple:
///////////////////////////////////////////////////////////////////////
var a:MyDataType = new MyDataType(100);
var b:MyDataType = new MyDataType(200);
b = a; // no MyDataType::MyDataType(const MyDataType&) or MyDatType&
MyDataType::operator=(const MyDataType& other) will be call
///////////////////////////////////////////////////////////////////////
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 2 in thread
Cepera wrote:
> Then I assign one variable to another only QObject* copies, not real
> value, why?
> It's a bug or a feature?
>
> For exmaple:
>
> ///////////////////////////////////////////////////////////////////////
> var a:MyDataType = new MyDataType(100);
> var b:MyDataType = new MyDataType(200);
>
> b = a; // no MyDataType::MyDataType(const MyDataType&) or MyDatType&
> MyDataType::operator=(const MyDataType& other) will be call
> ///////////////////////////////////////////////////////////////////////
Hi Cepera,
This is by design.
-
Gunnar
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 3 in thread
And I should call "a = new Type(b)" instead of "a = b;" to make a copy
value?
"Gunnar Sletta" <gunnar@xxxxxxxxxxxxx> wrote in message
news:449F8C47.1080408@xxxxxxxxxxxxxxxx
> Cepera wrote:
>> Then I assign one variable to another only QObject* copies, not real
>> value, why?
>> It's a bug or a feature?
>>
>> For exmaple:
>>
>> ///////////////////////////////////////////////////////////////////////
>> var a:MyDataType = new MyDataType(100);
>> var b:MyDataType = new MyDataType(200);
>>
>> b = a; // no MyDataType::MyDataType(const MyDataType&) or MyDatType&
>> MyDataType::operator=(const MyDataType& other) will be call
>> ///////////////////////////////////////////////////////////////////////
>
> Hi Cepera,
>
> This is by design.
>
> -
> Gunnar
>
> To unsubscribe - send "unsubscribe" in the subject to
> qsa-interest-request@xxxxxxxxxxxxx
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 4 in thread
Now I realize via QSObjectFactory, because if I use slot, then I should
delete object by hand, because QSA don't destroy object created in slots ...
Thanks for quick and irrefragable answer
----- Original Message -----
From: "Gunnar Sletta"
To: "Cepera"
Sent: Monday, June 26, 2006 12:05 PM
Subject: Re: variables assignment
> Cepera wrote:
>> And I should call "a = new Type(b)" instead of "a = b;" to make a copy
>> value?
>
> QSA will not call the copy constructor or the assignment operator for you.
> Primarly because most QObjects have the copy constructor and the
> assignment operator disabled because it would destroy the d_ptr.
>
> If you implement a QSObjectFactory::create() function that makes a deep
> copy of the type based on your own logic then the above method would work
> just fine.
>
> Alternativly you could introduce a copy() slot that returns a deep copy of
> the object in question.
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 5 in thread
You can add the pointer as a transient object to the interpreter if
you want it to delete the object for you.
Brad
On Jun 26, 2006, at 4:08 AM, Cepera wrote:
> Now I realize via QSObjectFactory, because if I use slot, then I
> should
> delete object by hand, because QSA don't destroy object created in
> slots ...
>
> Thanks for quick and irrefragable answer
>
> ----- Original Message ----- From: "Gunnar Sletta"
> To: "Cepera"
> Sent: Monday, June 26, 2006 12:05 PM
> Subject: Re: variables assignment
>
>> Cepera wrote:
>>> And I should call "a = new Type(b)" instead of "a = b;" to make a
>>> copy value?
>>
>> QSA will not call the copy constructor or the assignment operator
>> for you. Primarly because most QObjects have the copy constructor
>> and the assignment operator disabled because it would destroy the
>> d_ptr.
>>
>> If you implement a QSObjectFactory::create() function that makes a
>> deep copy of the type based on your own logic then the above
>> method would work just fine.
>>
>> Alternativly you could introduce a copy() slot that returns a deep
>> copy of the object in question.
>
> To unsubscribe - send "unsubscribe" in the subject to qsa-interest-
> request@xxxxxxxxxxxxx
>
>
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 6 in thread
I found that QSA is not freeing the wrappers as I expect from it
I have some slot that return descendant of QObject* in slot:
QSTreeItem* Base::getFirstItem() {
...
return new QSTreeItem(...);
}
I made a wrapper factory, that will "wrap" the object with itself :
QSWrapper::QSWrapper() {
registerWrapper("gui::QSTreeItem");
}
QObject* QSWrapper::create(const QString &className, void *ptr) {
if (className=="gui::QSTreeItem") {
return (QSTreeItem*)ptr;
}
return NULL;
}
I registered the factory with interpreter.
Debugging calls suggest that the QSWrapper::create is executed as it should
I executed (in context of Base) script code:
for(i=0;i<50000;i++) {
x=getFirstItem();
}
... and the constructor of QSTreeItem was called 50000x and destructor ...
never (well, the objects were cleaned up when the interpreter was destroyed,
but that is too late, cause the interpreter is not destroyed until the
application is closed and in the lifetime of it, many similar scripts with
long loops are run).
The docs says "The created wrapper is deleted by the interpreter as at some
point after that the interpreter determines that there are no more references
to the wrapped type from script." but that seems to be not true, as IMHO after
that loop there are 49999 unused references somewhere.
Am I doing something wrong, or is there some serious bug in QSA?
I am using QSA 1.1.4 ... the newest that is out for QT3
Martin Petricek
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
