Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Scripting garbage collection and destructor


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 lephyrius   Members   -  Reputation: 355

Like
0Likes
Like

Posted 15 October 2013 - 01:18 AM

I've been thinking of using Squirrel as a scripting language.

My idea was to use the garbage collector as a memory manager:(squirrel as an example script)

class Model
{	
	constructor(filename)
	{
		model_id = load_model(filename);
	}

       destructor() 
       {
                unload_model(model_id);
       }
       								
	model_id = null;
}

Something like this.(load_model and unload_model is native functions that are really easy to bind no need to worry about binding complicated classes)

It's obvious that this isn't going to work. Because Squirrel is missing the destructor.

Am I thinking of something wrong?

Is there a reason why Squirrel doesn't have a destructor?

Am I just using scripting in a wrong way?

Are there any alternatives to Squirrel that is similar to it but with a destructor?

Should I rethink the problem with binding to the native functions?



Sponsor:

#2 frob   Moderators   -  Reputation: 29877

Like
6Likes
Like

Posted 15 October 2013 - 02:08 AM

Object lifetimes are not limited to construction and destruction. They are convenient hooks, certainly, but they are not everything.

Even following RAII principles, an object can be fully constructed and still not use any resources or be bound to data sources. In fact, it is often a bad idea for it to be hooked up during construction. Similarly waiting for destruction to release resources or to unbind sources is often a bad idea.

Consider you constructor above. Let's say you wanted to create 50 models. Each constructor requires a file name, and construction cannot complete until a model is fully loaded. What happens if there is an error loading the model? If anything goes wrong -- even a fairly routine development problem like a wrong file name or a corrupt data file -- the code has no sane response. The lack of a default constructor makes many forms of bulk creation become unwieldy or impossible. And exactly what is involved in loading a model? Is this code really taking multiple trips out to disk to first look up the file name and then to load the model and texture and other resources? Hopefully you won't need the constructor during any time-sensitive code!

A classic problem in C++ destructors is that while they give a convenient place to close resources and otherwise clean up, in large projects that should generally be more of a failsafe and less of a common situation. Release resources as soon as you are done with them. While that may happen to be when the object goes out of scope (and hence a C++-style destructor is appropriate) objects with longer lifetimes rarely follow such a pattern. Also in the grand scheme of programming languages, the C++-style destructor is a very rare language feature; programmers in most languages are generally expected to manage object lifetimes in a more thoughtful way.

Many languages consider object lifetimes in more phases, and many games follow them as well. There is a phase when the object is minimally created and initialized. That quick minimal creation should never mean journeys out to disk. There can be phases when the object is hooked up to data, such as open() or connect() or load(). And there are phases when those resources are released with close(), disconnect(), unload(), or dispose().

In well-written C++, the destructor is often just a set of lines like:
if(connected) disconnect();
if(open) close();
and otherwise doing tasks that the programmer ought to have done already, but for some reason might not have done.


Get used to using proper lifetime management functions (rather than just the binary constructor/destructor pair) and programming life will become much easier in the long run.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 lephyrius   Members   -  Reputation: 355

Like
0Likes
Like

Posted 16 October 2013 - 10:43 AM

I've been thinking about this.

You are right it has really opened my eye to something also it's really nice and cache friendly to store models in that way.

The problem is that isn't scripting languages one the reasons of using a scripting language is to use the garbage collector.

 

Hmmmm...

Clean up after a level is loaded shouldn't be a problem when all the allocations are controlled by the engine itself. It certainly is faster to deallocate chunks of memory also more cache friendly.(almost feels like my C++ code becomes more C like)

The thing is that I was thinking that scripting should be more a part of the engine rather than just a slave to the engine.



#4 Krohm   Crossbones+   -  Reputation: 3886

Like
0Likes
Like

Posted 17 October 2013 - 01:07 AM

As a side note, GC collected languages generally have finalizers instead of destructors. They're almost the same thing but with an important difference: dtor is called deterministically while finalizer is called "at some point in time" immediately before object is cleared.

This gives an important implication: most of the time you need to "clear" (in gameplay terms) an object as a response to an action.

I've witnessed a dude cracking his head open at a bug originating exactly from this behaviour: he expected an object to go away immediately after dropping its reference. This of course wasn't the case and since he tied existence to visualization, some sprites appeared to be all over the place.

 

So, maybe this is not completely related to your needs but I hope it helps you thinking.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS