C++ and Game Development Articles

[Nexus]

Hello

Once I'm not writing about a library or a game. On my homepage, I added an Articles section which I use to write about a few topics related to C++ and Game Development. I will probably focus on the C++ part, but I have no concrete plans yet.

The articles won't appear in a regular fashion, it's not a blog with monthly or weekly updates. I'm writing them when I find time and a good topic to investigate, and I personally like this approach more than an enforced schedule where quality might suffer. I'm also open for suggestions, and I might improve the articles over time.

Anyway, the first article is about RAII, my favorite topic
Since this topic appears again and again on the forum and there are so many people doing memory management wrong, I tried to come up with a summary about the whole topic and a detailed analysis of its advantages, as well as an investigation of all the counter-arguments. The article is an extension of the post Why RAII rocks that I started. This thread is a nice example of a discussion about RAII, and I tried to extract the arguments of both sides and confront them with each other, creating an overview about the whole issue. Thanks to all the people who contributed in that and other discussions, you've really helped to gather good points. I hope the article helps us in the future, so that we might refer to it instead of repeating the same arguments again and again.

Links:

• Article site: www.bromeon.ch/articles/
• First article: www.bromeon.ch/articles/raii.html

[zsbzsb]

Looks good Nexus 

Can't wait for more articles 

[eXpl0it3r]

Awesome! Finally a nice overview on that topic to hand to everyone!

Looking forward to more awesome content.

[AlejandroCoria]

Very good article! keep it up.

[MadMartin]

That's great!

I'm looking forward to reading more of your articles.

[Lolilolight]

Things are not so simple than that.

You have just to know what class is responsible for the allocation and deallocation of a kind of object, and, it's not always the object that contains the pointer who's responsible for it's deallocation. (And when you have to pass a smart-pointer to a class or a function, it's a waste of time.)

When you have some experience you can get rid of a smart pointer, you just have to know wich class is responsible for the allocation and deallocation, and don't use the manual memory management directly in functions. (Who can as you say, throw different exceptions and have more return cases)

And it's strongly recommanded for all objects to redefine a copy constructor, the operator=, and the destructor. (And know we have even the move semantics who seems to really roks)
And if objects are not copiable to declare the operator= and the copy constructor in the private part of the class. (But I don't like to do that, I prefer let the chooise to the user to copy the object if it's very necessary)

We always learned to redefine the copy constructor, the destructor, and the operator= even if the objects don't contains pointers.
It can seemms boring to do that if it's not necessary but, it's a good practice.

[Lo-X]

Yeah ! I can't read the whole article since I'm at work (hum :p) but I know it rocks at least as much as your forum post about RAII.

I too can't wait other articles ! Like everyone else :p

[Nexus]

Thanks for the nice feedback

When you have some experience you can get rid of a smart pointer

No, then we're back at square one. As I emphasized in the article, using RAII is not a matter of whether you are experienced enough. See point 3 and 5 in the myths section.

And it's strongly recommanded for all objects to redefine a copy constructor, the operator=, and the destructor.

No, the opposite is true. The more often you need to define the Big Three/Five, the more this is a hint that you did a poor job at abstracting. Ideally, class members should know how to be copied and moved themselves. There are of course cases where you need the Big Three/Five, but it should definitely not be the default. Search for "Rule of Zero" if you want to know more about that.

We always learned to redefine the copy constructor, the destructor, and the operator= even if the objects don't contains pointers.
It can seemms boring to do that if it's not necessary but, it's a good practice.

Yes, you've learned it wrong. It's never a good practice to write code that the compiler can write for you. You only waste time and risk making mistakes.

[AlexAUT]

Really good article, as I expected 

Can't wait to see more articles about more specific topics! Keep up the good work.




AlexAUT

[FRex]

There are also cases when ints or pointers that don't own resource are in use = manual 'management' but no leak danger or new/delete.
For example my shadow code(using Box2D dynamic tree) uses ints as line ids inside the tree.
Box2D gives back pointers to objects that you mustn't call delete on but need to call member function on some object that created them and pass them in.
In both cases you don't have new/delete in your code and forgetting to call right deleter function won't cause memory leak(the ShadowWorld / b2World still delete all their contents) - it'll cause logical bug(shadow or body or joint living too long, after it's game entity died, etc.).
Yes, there are custom deleters but you seem fixated on new/delete and memory leaks and management. Maybe you could talk about/show examples of custom deleters too? That is 100% RAII too but has nothing to do with memory management, new, delete or leaking, it prevents logical bugs.

[Lolilolight]

Sorry but I don't agree with you nexus, I've had many compilation problem with SFML but also with the std::ref of the standart c++ library, and mainly with function pointers who are removed implicitly by the compilator when a member variable of a class is declared as non copiable and don't redefines the copy constructors, you're forced to use a pointer so.

This is not a good practice.

If you need to have a singleton or a smart pointer who's similar, you'll have compilation problems.

So don't always trust the compilator, it works well with pointers but..., for the rest, it's very dirrerent.

And even with pointers it can lead to compilation errors. (So it's not really better than memory leak)

[Nexus]

There are also cases when ints or pointers that don't own resource are in use = manual 'management' but no leak danger or new/delete.

No, it's not memory management if you don't own the resources. Raw pointers that only act as indirections to objects, without ownership, are harmless. Maybe I could state that in the article.

I've had many compilation problem with SFML but also with the std::ref of the standart c++ library [...]

This is not a good practice.

It's not a good practice because you had compile problems?

Just tell me one reason why you should declare copy constructor, assignment operator and destructor if the compiler-generated ones work fine. Because that's what you claim: "And it's strongly recommanded for all objects to redefine a copy constructor, the operator=, and the destructor."

By the way, if you consider compile problems the real issues, then you can be glad. Runtime errors such as undefined behavior are much trickier to solve, or even detect.

So don't always trust the compilator, it works well with pointers but..., for the rest, it's very dirrerent.

Of course I trust the compiler. And I recommend you to do the same. If it doesn't do what you expect, then it's in 99.9% of the cases because you misunderstand C++. Do not assume it's a compiler bug because something doesn't work the way you want it to.

If you have no trust in the compiler, there is no point in using it in the first place...

[FRex]

No, it's not memory management if you don't own the resources. Raw pointers that only act as indirections to objects, without ownership, are harmless. Maybe I could state that in the article.

(Please notice I said 'management', not 'memory management').
I'm talking about pointers and handles that have ownership but not using new/delete. It's not memory management but it's management and it can be eased with RAII. There is simply no danger of leak overall because the real owner that you ask for object will delete it before program exits but more often than not forgetting to call right freeing function results in logic error.

[Nexus]

Ah, I see. Irrlicht also does that a lot, by returning pointers to scene nodes or other objects that will eventually be torn down along with the whole scene graph, but you can also explicitly release them earlier.

There are many applications for RAII, it's an idiom for resource management in general. A few use cases apart from memory are shortly mentioned, but I think it would be out of the scope to explain them in a detailed way, since the article focuses on memory management.

[Grimshaw]

Nice article!

I love your insight on this topic, as well as many other c++ related discussions for that matter..

I still have to migrate my coding for full RAII compliance (damn I am stubborn :p). I still use manual memory management in a few cases, especially if the instancing and releasing of the objects are centralized somewhere, I just prefer using new/delete. But I do recognize its a bad practice, even if nothing is logically wrong in there.

@Lolilolight - don't mean to offend, but please take some time getting acquainted with the c++ 'compilator' and language in general. It will help you a great deal in all your projects, but this topic quickly gets flooded with discussions that barely matter on the topic.