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?

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.

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.