Alright. Just a quick question about LUA, and going to use Hadron Collider as an example. I'm wondering how to free up resources, as I know LUA has some form of garbage collection. So let's make up a quick sample of random code:
HC = require 'hardoncollider'
Collider = nil
function love.load()
Collider = HC(100, onCollide)
-- do stuff
end
-- other functions ......
function deleteCollider()
Collider = nil
end
Would this remove all the memory that Collider has used? Or, would we also have to remove everything that's within the Collider object? ie Collider:remove(shape), then set it to nil? Or is there a more proper way to removing objects you no longer need.
Maybe using collider was a bad example, but you probably get what I mean.
Yes, it effectively will. Once Lua thinks it occupies too much memory, it will run a garbage collector, and everything that didn't had any references to it gets collected. Lua GC can handle correctly tables referencing to themselves, thus it (up until certain extent) can collect memory islands as well.
The general idea is that in Lua, you never have to worry about it. Start coding C++ and it's a whole another story.
That said, I'd still advice to avoid creating large amounts of tables every love.update or love.draw, because if you do you'll eventually run the (quite slow) garbage collector more than necessary. I've never been able to notice any performance issues from this, though, so I think you'll have to write it pretty badly before you notice any issues.
Try running your code on a slow machine and you will notice every single bad place.
As for C++ (actually plain C), I like it better to handle memory manually. This way I can effectively re-use it easily, and I will never run into problems with GC. Of course it takes skill and maybe talent to make your program flawless, but it's entirely possible to have every single thing under control.
Not necessairly, if you design your thing well before you get to do it. Of course it takes less time to program if you don't bother over designing your program and over delete statements, but you would know up to what extent you'd be called a crapcoder for that.
I'm actually convinced that if you could code C++ as fast as other, higher level languages, no one would ever bother with higher level languages. Being able to develop stuff faster is pretty much the only thing they're good for.
Not just every higher level language. Only those that allow really crappy code to run. C++ won't stand it, so if your team is a bunch of monkeys then your C++ project will take way more time than, say, PHP project. But if team members are skilled coders, you won't see difference. Also, 95% of those languages success on the market was false advertising targeted at managers in response, who seem to beleive shiny booklets (that claim their crap to improve this and improve that) more than actual practice. Oh and it's way cheaper to hire a bunch of monkeys instead of qualified professionals, of course.
If C++'s syntax didn't make my head spin, and I didn't need to write something like 200 lines to get a basic winmain/window setup I'd likely use it more often. As it stands if I need to throw something together, C# is usually my goto language, though I've dabbled in python as well. And once you start working with boost or STL C++ just turns into a complete and utter mess. It's so... cluttered, and verbose.
That said, I like some of the features C++ has.. like not requiring you to spend ages trying to find a .net wrapper for your library of choice (alternately, not having to roll your own)...
