next »

[Klaim]

Average Software> I fully agree with what you said, dynamic memory is often overused. I share the same kind of anecdote of not having to use new/delete at all or in one specific place only. I also agree about the education problem from people coming from C# & Java. I'm not really preaching it, but mostly saying that they should be preferred if you have to manipulate objects allocated in dynamic memory.

You have to consider that stack might be not enough memory for some use, like some memory-consuming games and embedded hardware.
So I'm talking about cases where you MUST use dynamic memory.
Assume that you are in this specific case, you can 1. use smart pointers 2. use new/delete 3. use malloc/free. There is only one safe way to do it (answer:1). (to be complete for those who don't know, 2 & 3 are useful when you have to implement high level abstractions with low level expressions, typically when you want to implement a memory pool)

I think it's hard to express the fact that there are good solutions in a language that are idiomatic, without looking like a guy abusing them. It's, on the contrary, about composing with your tools.
Maybe it requires lot of experience... or maybe education/knowledge-spreading can help.

[igor]

@Klaim (or @anybody_using_modern_c++_heavily really): Could you provide a link to some freely available source code that, in your opinion, uses modern C++ well? Preferably something game or gametech related (not some huge general purpose library). It may sound silly but I don't think I have seen anything like this, all code I have worked with (including my own) was rather oldschool ("C with classes" with occasional template here and there) - mostly due to the age of the code or the age of the programmers :-)

[PompiPompi]

Err, there is nothing wrong using dymanic memory as long as you remember to delete it.
Most of the time you won't need to do heavy lifting with dynamic memory(yourself), because you would use STL instead anyway. For instance std::vector, std::list.
I do agree smart pointers, or at least reference counters are important, but not everywhere. They are mostly useful when you have seperate modules(dlls\libraries), because you can't practically delete memory that was allocated from inside a library(supposingly a black box). You can, but it ruins the whole point of having a seperate module.

[Klaim]

@Klaim (or @anybody_using_modern_c++_heavily really): Could you provide a link to some freely available source code that, in your opinion, uses modern C++ well? Preferably something game or gametech related (not some huge general purpose library). It may sound silly but I don't think I have seen anything like this, all code I have worked with (including my own) was rather oldschool ("C with classes" with occasional template here and there) - mostly due to the age of the code or the age of the programmers :-)

Game related there is not much. Boost is the authority in the domain, but depending on the library you're reading you might be completely lost in meta-programming land (or not).

For game related code, the only one I know that is public is mine, but it's not a good example because it's a bit old or too prototypy (12h from scratch).

[Klaim]

Err, there is nothing wrong using dymanic memory as long as you remember to delete it.

What he means is that most of the time you don't need dynamic memory, even if it don't seem so.

[PompiPompi]

Well, it depends what you mean by most of the time.
It's like I would say, "hmm, most of the time you don't need a float".
As I said, you can use std::vector<T> instead of T *, in many cases. So if that is what you mean then I agree. and std::list instead of implementing your own list and etc. And a reference counter for libraries. And there are other things.
Maybe we both think the same, but just argue on the explaination and semantics, heh.

[Klaim]

Hehe explaining in text only in a rush can be so misunderstanding. (not even sure it's english but I'm in a rush...)

[ntdb]

Bruce Eckel's Thinking in C++ comes highly recommended and is free to download: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

[Klaim]

When I figured I didn't really know C++, I re-learnt C++ by reading books starting with this one.

Also, Heads Up C++ and Accelerated C++ are often cited as good introductory books to modern C++.


Just know that the new standard (C++11) might make some previously encouraged idioms obsolete or simpler : http://stackoverflow.com/questions/9299101/what-c-idioms-are-deprecated-in-c11
And some new up-to-date litterature will come starting next year, as current compilers already started to support some C++11 (the next version of gcc seems to have almost all that is visible syntactically).

[Will Vale]

However, I need to point some things.

Wow, epic response. I think much of what you've said is just confirming that we disagree

It also seems that you think I dislike or disapprove of C++ - I don't, I think it's a great language, but it's complex and using it effectively is more difficult than using C effectively. It's easy to write bad (slow, unmaintainable) code in C++.

why make things harder by not using useful abstractions

I didn't say don't use these things, I said "be aware of their cost" and "be aware that problems can be solved in multiple ways" - idiom shouldn't be dogma.

I understand that it's more a short-term strategy than a long term one, so it's fine in a pragmatic way.

It's actually the other way around. From experience with the real costs of these features you can be more aware of where they can be used and where they shouldn't be.

e.g. if you're writing asymmetric MP code (e.g. GPGPU or SPU) then the more C++ features you use the harder your life will be when you try and load-balance by moving work between different types of core. If you use fewer features you will be able to move the work easily, or even cross-compile for the different cores so you can debug on one core and run on another.

Most just don't have the time to learn what is the current state of C++ and why they should care, so it's totally understandable that they still rely on old C++ context to decide what to use or not.

I'm sorry but that just comes across as patronising. I hope it wasn't meant like that

All that said, I din't ship a complete commercial indie game alone myself yet so, let me prove my points in a hopefully short future, will you? 

Fair enough, I haven't either, and I think if you're working on your own you can have a much freeer hand in how you design and approach things because it's only your productivity that matters.

FWIW I used to be really excited about new language features and modern idioms, but over the last 15-odd years time I've found that the subset of C++ that covers 90% of my day-to-day use gets smaller rather than larger. I don't think that's just from cynicism and ignorance.

Well OK, maybe some cynicism I am really looking forward to the new auto keyword though.

Good luck with your personal project!

Will

[paste]

@Average Software: Would you (or anyone else for that matter) be willing to share a segment of code or a situation where someone less experienced would use dynamic allocation and a redone version of it using value semantics? I've only just heard of it, and I'm one of the people you are probably talking about that overuses "new". As such, I find it much easier to learn from example and then abstract idea, so an example would be of great help.

[InfiniteStateMachine]

yeah I would also like to see that. Also thank you ntdb for posting that book link. Does that particular book espouse the virtues of avoiding dynamic allocation as well.

I can certainly see the benefits of avoiding dynamic allocation. I guess I have a new goal for my next C++ project.

[Will Vale]

You might not want to avoid it altogether, but it's definitely a good mindset because it makes you face up to the problem that computers have limited resources.

One interesting question which usually comes up is how to deal with having N of something, like bullets, and not really knowing how many N is. This is different to the case where each bullet is on the heap, or in a std::vector, and you just add one when you need it.

The simplest solution is to decide the max number of bullets you will allow, and then figure out what to do if you run out. You lose flexibility, but you gain predictable memory usage, and better memory locality (all your bullets are close together so they'll usually be faster to access). You also explicitly handle running out of bullets at a high level, so your game won't run out of memory or start hitting the swap file when it runs out of resources at the lower level.

(NB: This works when allocating on the heap too.)

@Average Software:
Going for full-on value semantics sounds interesting, do you find your program spends time copying complex values around, or do you do read-only access by reference?

Will

[BlueSweatshirt]

Or linked lists.

[Average Software]

Bruce Eckel's Thinking in C++ comes highly recommended and is free to download: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

I actually did not find this book very good at all, I owned a physical copy at one point, along with Eckel's Java book, and I didn't like either of them.  Unfortunately, I can't recall exactly what I didn't like about them.

My favorite C++ books are Stroustrup's and this one.  It covers modern C++ template programming in exhaustive detail, and one of the authors is on the compiler team that produced the only successful implementation of the export keyword, so this dude knows what he's talking about.  I'm not sure if I would recommend it now, since C++2011 has expanded templates by quite a bit, so the book may now be outdated.

Going for full-on value semantics sounds interesting, do you find your program spends time copying complex values around, or do you do read-only access by reference?

I have not found any measurable performance issues, since most of the copying occurs either once, or in code that is not particularly performance sensitive.  I've moved from C++ to Ada for most of my large projects, and this approach is much easier to use in that language due to support for polymorphic copying and value-based polymorphism, but there's no reason you couldn't do it in C++.

The key to it all is to manage your data by value, and process it by reference.  I tend to go for centralized data stores rather than having several things competing for 'ownership' of resources.  This is another reason why I tend to shy away from smart pointers, my memory management structure simply doesn't need them, since memory is clearly owned by particular modules.