[Scilab-users] Counter of pointers to an XML object, and clear destructor

[Antoine ELIAS]

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 at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20180730/797e8c89/attachment.htm>