Learn to program

[Ishtvan]

I'm not a real programmer, but I found SmallTalk to be helpful for learning OO stuff, since it kind've forces you to do everything that way. It's been years since I used it, but I think my only complaint was that you had to write all your own garbage collection.

[Crispy]

I'm not a real programmer

Says one of TDM's main programmers. Sheesh.

[Ishtvan]

Yeah, I generally just mash some buttons together and poke the magic computator box with a broom until it does what I want. I think it's powered by gnomes somehow.

[Crispy]

1. Do Ishtvan's bidding

2. ???

3. Profit!

[Domarius]

What do you mean you're not a real programmer? You're only quasi-real because you're half shifted from another paralell universe?

 

Writing your own garbage collection is good practice anyway.

[OrbWeaver]

Writing your own garbage collection is good practice anyway.

 

Not really . Re-inventing a square wheel when there are tried, tested and robust round wheels already in existence is very bad practice indeed.

[sparhawk]

It depends. If you rewrite it because you want to know how it works, that's ok. If you rewrite it, because you need one, and you haven't even looked at all the other solutions, that's indeed bad practice.

[OrbWeaver]

If you rewrite it because you want to know how it works, that's ok. If you rewrite it, because you need one, and you haven't even looked at all the other solutions, that's indeed bad practice.

 

Good point -- I took Domarius' use of the phrase "good practice" to refer to best practices in design, when in fact this could equally be referring to "practising" certain programming techniques for learning purposes.

[Domarius]

Yeah I meant practicing.

 

I might be showing my lack of experience, but asides from Java's automatic garbage collection, what else is there at the moment? I know you do it manually in C++, because you want to be in control, and say you complete one level in a game and move onto the next, you want to ensure the previous level is all flushed before the loading screen, making room for the next one, and not randomly occouring during the next level causing frame rate stutters and taking up memory.

[Crispy]

I know you do it manually in C++, because you want to be in control, and say you complete one level in a game and move onto the next, you want to ensure the previous level is all flushed before the loading screen, making room for the next one, and not randomly occouring during the next level causing frame rate stutters and taking up memory.

That's not actually such a problem as long as you manage the garbage collector responsibility (which almost nobody does). Most garbage collector implementations will have a way for you to tell them "do a full sweep now and don't return until you're finished", so you'd just call that to flush the previous level after dropping all references to that level's data (though explicitly freeing things is a responsible thing to do, even when you do have a GC on hand). And as long as you explicitly destroy objects that are being created on a regular basis mid-level, the garbage collector shouldn't be invoked mid-level much at all, making it practical for action-oriented games; obviously you can get away with being a bit lazier if the game is more slow-paced. And there are implementations where you can cap the amount of time spent in the GC, so the CPU time cost gets amortised over a longer period.

 

Basically the idea is that you can (and sometimes should) still manage your own memory - the GC is just there for when you're lazy, and to save you from yourself when you screw up.

 

Lots of newer languages besides Java use garbage collection these days; C#, D, Python, Ruby, the list goes on and on.

[OrbWeaver]

You don't have to use unpredictable garbage collection either; implementations like boost::shared_ptr use simple reference counting so that a resources is destroyed as soon as the last reference to it disappears, rather than some unspecified time later in a separate thread. GTK does this as well with its GtkWidget elements.

[Domarius]

Ah I never thought of shared pointers as a form of automated garbage collection.

[OrbWeaver]

Technically I don't think it qualifies as "garbage collection" but it has the same effect: automatic memory management.

[Nyarlathotep]

Generally, garbage collection involves implicit, lazy deallocation of memory, whereas shared pointers involve implicit but strict deallocation (you know it will happen when the last reference is deallocated). With shared pointers, you're explicitly deallocating the references, and you know that when you get rid of the last pointer it will deallocate then, not the next time the garbage collect algorithm decides to run.