Squirrel

Hi all,

I have been reading the forums and I have seen there's a way to be notified by squirrel thorugh a C++ calblack when a instance is destructed. But what about classes not descending from any class in the C++ side?.

Another question, if I create an instance of a class and keep it in a table and later I "null" it. Should I suppose it will be garbage collected? If I use delete keyword instead of null it will have the same effect?.

Example:

local Instance= Class();

Table[0] <-Instance;

Is it the same if I do (Just have in account if instance is gc colecter or not, not he state of the Table after each operation):
1)delete Table.0
2)Table[0]=null

Thanks in advance,
HexDump.

-on script side there's no way to be notified on destruction.

-delete and nulling has the same result in your case (delete doesn't delete the object but the table slot pointing to it).

Alberto

Thanks for the answer Alberto.

This line you wrote confuses me a little:

-delete and nulling has the same result in your case (delete doesn't delete the object but the table slot pointing to it).

Delete doesn´t delete the object yes, but if the table slot is the only one referencing the object gc will delete it in the next iteration (same thing when nulling the slot). Am I right?.

About the notify thing, I feel a bit stressed :D, because my experience with squirrel is little (learning it as fas as I can though) and I have to rely that things are deleted without proving it :).

Thanks for you work and patience Alberto and keep the good work!
HexDump.

@Alberto:

Would it be possible (or would it even make sense) to add destructors to squirrel? It could be used for logging and performing some other actions (although it would be rarely needed).

I'd like to know your point of view, since you didn't add it to squirrel.

hexdump: yes if nobody references an object, it will get deleted(immediately... squirrel is ref counted).

cya: it could be possible to have a destructor but it would be expensive and it would drag in a lot of problems like object resurrection. What is the VM going to do if the destructor assigns the 'this' object to a global?....things of this kind. It can be done, but it's messy. I don't like messy :)

Alberto

Thank you for your reply.

I definitely understand your arguments ( even if I would never had the idea to assign 'this' in the destructor :)).
I also don't think there is a real need for destructors either (see python, it has destructors, but they are rarely used), since there is no dynamic memory allocation on script side.
Destructors could still be useful (for example for closing files, network connections etc...), but if you say that it would be expensive, it's probably best to leave it out.

I had to implement destructors in my game since it's use a orthogonal system of entities, in which they register in global lists, such as render list, tick list, etc. So when the entity is destroyed it must be removed from these lists.

But I assumed a few rules, no object ressurection, no accessing of the other objects, no cyclic references, etc. But it's still raise some problems, for example on sq_close it runs a GC soon after nulling the root table, the registry table and the main stack, so if you try any script manipulation on the destructors called at this moment it will crash your app. So you must verify this cases also.

cya:

Destructors could still be useful (for example for closing files, network connections etc...), but if you say that it would be expensive, it's probably best to leave it out.

this is already possible, from C++ side you can get notified of destruction. Take a look at sq_setreleasehook(). That's exactly how the file object in the standard library closes file handles.I Personally never had the need of a destructor squirrel side. In our engine the only objects that need notification are the one that have some C++ data attached to it(like entities) and for that the release hook is all you can wish for.

I hope this helps

Alberto

I already knew that, but thanks anyway. What I meant were script side destructors, but I agree that you will only need the c++ ones in most cases (file and networking is usually on the c++ side, so it was probably a bad example).