Hello Samuel,
In XMLObject there is two levels of reference,
- one on MList (managed by reference counter)
- one on internal XMLObject (internally manager like handle, an
integer that link to a C++ object)
xmlDelete destroy internal XMLObject
clear destroy (unreference and destroy if ref <= 1 ) MList object.
So in your case, after a xmlDelete, the internal XMLObject was destroyed
but not the MList.
And after a clear doc, the MList was destroyed but the internal
XMLObject not.
Current XMLObject is based on simple MList with the id of the doc (
store as double ).
If we want to correctly destroy the internal XMLObject with the clear
command.
We must change the implementation to use types::UserType instead of
types::Double and uses destructor of UserType to free XMLObject.
> Deleting an object should clear all its pointers. For instance, with
the XML example
> hereabove, deleting the document should clear doc and doc2.
I am not agree with that, I cannot delete an user variable indirectly. (
xmlDelete(doc) that will delete doc )
Only clear command can do that. For me it will be a bad practice.
Antoine
Le 28/07/2018 à 16:20, Samuel Gougeon a écrit :
Hello,
I am doing some tests about the save() function, in order to document
its behavior when saving pointers to some objects.
There is the case of XML objects:
Contrarily to graphic handles, that are pointers whose reloading
restores the pointed graphics, saving XML pointers is possible, but
then their reloading does NOT restore the XML document.
Then, when digging in Bugzilla in order to search for features about
this and the clear() function applied to XML pointers, i've found back
the following comment from Calixte
<http://bugzilla.scilab.org/show_bug.cgi?id=13398#c2>, referring to an
expected change of Scilab 6 with respect to Scilab 5:
/With Scilab 6, things will be easier since each data will have a
reference counter [of pointers to it] which will allow to call a kind
of destructor when the reference count will be zero.//
/
In practical, this new feature looks still not to be implemented. Here
is an illustration:
// Let's create an XML document and a pointer "doc" to it:
--> doc = xmlReadStr("<root><a att=""foo""
rib=""bar""><b>Hello</b></a></root>")
doc =
XML Document
url: Undefined
root: XML Element
// Now, let's make a copy of the pointer:
-->doc2=doc
doc2 =
XML Document
url: Undefined
root: XML Element
--> doc2==doc
ans =
T T <<< this double True is strange, but it's not the matter here
// Then let's clear both pointers: If a counter actually exists,
// it shall be set to 0 afterwards.
// And if the automatic destructor is implemented, then this should
// automatically delete the XML document. What's the reality?:
--> clear doc doc2 // OK
--> xmlGetOpenDocs()
ans =
ans(1)
XML Document
url: Undefined
root: XML Element
The document still exists. So, the automatic destructor is not yet
implemented,
at least for XML objects.
Is it a pity? To me, the reverse approach would be more relevant:
Deleting an object should clear all its pointers. For instance, with
the XML example
hereabove, deleting the document should clear doc and doc2.
It's unfortunately not the case:
--> xmlDelete(xmlGetOpenDocs()(:)) // cleaning the area
--> doc = xmlReadStr("<root><a att=""foo""
rib=""bar""><b>Hello</b></a></root>");
--> doc2 = doc;
--> xmlDelete(doc)
--> isdef(["doc" "doc2"],"l")
ans =
T T
--> doc
doc =
-->
This is the same issue with graphic handles when the figure they point
to has been closed:
We then get some still existing /but invalid/ handles, instead of
properly clearing them.
Regards
Samuel
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
