next »

[Klaim]

Learn C

Yes, yes, a thousand times yes. Preferably before learning C++ - C is much easier/smaller, and everything happens in the open where you can see it.

If you're a good C programmer then C++ provides an awesome box of tricks that you will want to use, but naturally have some suspicions/reservations about. That's healthy.

I do not agree at all. Learning C will give the false impression of mastering the basics of C++ with additional tricks, that is totally false. Modern C++ isn't C, they are different languages that HAVE TO be learnt separately (and with distance) to benefit from both. C++ is NOT a stack of tricks over C, it's a different language that you write totally differently.

Too many people learning C++ go straight into the OO "class Car is-a Vehicle" paradigm and get stuck there. They also tend to accept or not even realise the costs of various language features.

That I agree with. This is not related to learning or not C. C++ provide several idioms, one being object orientation and as any language with object orientation, it is easily abused. The problem here is more a teaching/learning problem. Those developers you describe don't understand that a simple functions is a better abstraction for a big part of their code, instead of objects. But C have nothing to do with this.


C is good to know (assembly too - but I don't know much) but it HAVE to be taken as a DIFFERENT language.


Otherwise, you're the working on doom.

(pun intended)

[Will Vale]

I think that's a reasonable response, but I'm not sure I agree. I guess my "box of tricks" comment made it sound like I don't think that C++ is different/difficult, and I was trivialising the step from one to the other. That wasn't intended, I agree that it's a big step, that's partly why C first is a good idea.

They share some hard parts, like pointer arithmetic, memory management, etc. which are easy to "see" in C, but can be obscured in C++ by language features.

Going back to your "grok list", I don't think that RAII, or smart pointers, or STL, or OO are required fundamental concepts for making effective use of C++. They're all concepts which are outside the core of the language and inside one or more use paradigms.

Maybe the point we're disagreeing on is "Modern C++" vs. just "C++"?

I strongly agree about the importance of C (and asm) in a C++ context - it helps to know what's happening on the levels below the one you work at. Not always, but when you need it you really need it.

Will

[Klaim]

I think that's a reasonable response, but I'm not sure I agree. I guess my "box of tricks" comment made it sound like I don't think that C++ is different/difficult, and I was trivialising the step from one to the other. That wasn't intended, I agree that it's a big step, that's partly why C first is a good idea.

Yes that was my impression, so you're making it a bit more clear here, thanks.

They share some hard parts, like pointer arithmetic, memory management, etc. which are easy to "see" in C, but can be obscured in C++ by language features.

Yes, that's the point of C++, not having to deal with all that until you have to, at almost no cost.
That's also, in a more general way, why we use abstractions. That is, tools that help use hide details when they are noise when we're thinking a solution to a problem.
Most C++ code don't need to go to the pointer arithmetic for example, but it's good to know if you need it, in SOME part of C++ code, of SOME projects.

Also that depends on which feature you use, but the C++ guiding principle is that you don't pay for what you don't use. That means that if you try to implement an equivalent object-oriented architecture to solve a problem in C and C++, the C++ one will be less or as much expensive (on memory and speed) than C.

So, it's only useful abstractions to use when it helps solving your problems. (often only experience and a lot of literature on the project allow one to understand which abstractions are more suited for which kind of problem).

Going back to your "grok list", I don't think that RAII, or smart pointers, or STL, or OO are required fundamental concepts for making effective use of C++. They're all concepts which are outside the core of the language and inside one or more use paradigms.

What?

No, they are all precisely why C++ is not C.

Read this: http://programmers.stackexchange.com/questions/16390/what-are-the-fundamental-differences-between-c-and-c

By "use paradigms" you mean "idioms" right?

C++ idioms are not C idioms. When you use C++, you should dive entirely into the RAII idiom because it's the only way to get safe-efficient-clear-simple-correct code in C++. RAII "is" C++. The others are basic tools of the language (SL/STL) or very useful abstractions (OOP, templates) that need to be understood to use C++ fluently (as initially asked).

They are not "outside of the core of the language" at all, they make the language.
However they are outside of C language yes, because you wouldn't use most of those in C anyway as they are just not possible to implement. RAII is impossible to implement in C. STL is impossible without templates that are impossible to implement in C (macro are not templates at all). Object orientation, in the presence RAII, is impossible to implement in C (C way of doing OOP is fine and good, but it is nor safe nor easily correct and debuggable, while RAII imply that it is). Smart pointers are just impossible to implement without RAII then impossible to implement in C.

Smart pointers are the reason why you can write C++ code for years without never having any memory leak. (don't abuse them though) They don't replace you thinking how to manage your memory, they force you to know object's lifetime rules, with very very simple words (shared, unique, weak).

That said, I think it's really hard to understand all that without experimenting modern C++, instead of the old C++ that is often used in old C++ shops like most game development companies. So I understand if what I'm saying seems alien or wrong to any C++ user not used to idiomatic C++.

Maybe think it like this, if you know python: designing your code in Python like in C is not Pythonic (this is the name given to Python idiomatic code). In the same way, designing C++ code like in C is not idiomatic, therefore, it goes against the intended use of the language. It's a bit like when you have to fight your tool/engine to get a specific feature done. Maybe it's because it's not meant to be used this way.

Maybe the point we're disagreeing on is "Modern C++" vs. just "C++"?

What is commonly called "modern C++" is simply "standard ISO C++ with a correct implementation, using C++-specific idioms".

So, C++ is modern C++, but we have to make a distinction with "C with classes" that is the old way to work with C++ when it was badly implemented by compilers. It have been less than 10 years that we have more standard-compliant compilers.

Since we have them, we can code C++ code that looks like java/c# code but is predictable on the performance side and is more generic than in those languages. Mostly because of templates.

Since we have C++11 (last revision), we can write C++ code that looks more like Python code.

By the way, did you know that the last Stroustrup book, targetted at total beginners in programming, use C++ but don't introduce pointers until something like after 500pages? (it have 1400 pages I think). The book isn't specifically about C++, but it uses only this language. Before this point in the book, you build a calculator and start using GUI.

I strongly agree about the importance of C (and asm) in a C++ context - it helps to know what's happening on the levels below the one you work at. Not always, but when you need it you really need it.

The problem is more to understand when it is necessary to know/use. I almost never use my C knowledge these days, but I still work on high performance C++.

[Will Vale]

I don't think I have time to write a similarly in-depth response, sorry. I think we'll have to agree to disagree

I will say that IMHO RAII isn't a "native" part of C++, it's a way of working with the language, using a native feature (constructors and destructors) to accomplish something useful (freeing resources). If it was native, you wouldn't need to write wrappers or use libraries to get the desired behaviour.

The other features we've contested are even less native, they're entirely provided by external libraries I guess it's a semantic thing about where the dividing line is between internal features and external libraries, even if they're provided with the compiler toolset. I know that if I'm writing in C and want e.g. efficient file I/O for large files, streaming, unbuffered reads etc. I would forgo the stdio FILE* and go to the OS layer, so this isn't just an unwillingness to use the C++ std library.

That said, I think it's really hard to understand all that without experimenting modern C++, instead of the old C++ that is often used in old C++ shops like most game development companies. So I understand if what I'm saying seems alien or wrong to any C++ user not used to idiomatic C++.

This is a pretty common line about game development studios, it makes me sad because it assumes so much. Games have difficult problems to solve and using a language in "the intended way", whatever that is, may not be the right way to solve them.

Christer Ericson has some thoughts on this which I'd generally agree with, but it boils down to "If you want to ship complex high performance games on console systems, you need to pick and choose your language features carefully and be very aware of what they cost."

This is cost in compile time, complexity, transparency, as well as runtime performance and code size. These costs are important and features are never "almost free" - either they have no cost, or they have a cost of which you must be aware. If you're writing a smaller game, maybe you'll never worry about them on PC. If you port it to a 'phone or an embedded platform, maybe you'll need to worry about them then. In my day job I worry about them a lot.


Anyway, sorry paste for the thread hijack - there's been some good advice plus you can see the different opinions on the subject - there isn't a right answer, although I think Average Software probably said it best

My take is that most game companies will value pragmatic language proficiency derived from game development experience (either in a job, or on your own) over theoretical language proficiency acquired through formal learning. Courses are good and all, but the making and shipping games (indie or not) with your language is what teaches you the hard lessons. It also gives you something you can show off in interviews or as job application material.

Best of luck,

Will

[BlueSweatshirt]

Is it bad that in 5 years I have never used smart pointers?(or ever even learned about them)

[ஒழுக்கின்மை (Paul Eres)]

grok

grumble

i hate this word

i only mind the word when it's said by someone who never read stranger in a strange land

[ham and brie]

I will say that IMHO RAII isn't a "native" part of C++, it's a way of working with the language, using a native feature (constructors and destructors) to accomplish something useful (freeing resources). If it was native, you wouldn't need to write wrappers or use libraries to get the desired behaviour.

This "native" distinction you're drawing seems pointless. If you're not using RAII you're either not making effective use of C++ or hopefully you're doing something more advanced and risky having chosen not to use it.

Is it bad that in 5 years I have never used smart pointers?(or ever even learned about them)

It's not good if the reason you're not using them is that you've never learned about them.

[Klaim]

I don't think I have time to write a similarly in-depth response, sorry. I think we'll have to agree to disagree

Looks like it.
However, I need to point some things.

I will say that IMHO RAII isn't a "native" part of C++, it's a way of working with the language, using a native feature (constructors and destructors) to accomplish something useful (freeing resources). If it was native, you wouldn't need to write wrappers or use libraries to get the desired behaviour.

I didn't say it is "native", it's an idiom (resulting from the presence of destructors, yes) and it's what makes the difference between C++ (and ADA?) and almost any other language. If you experience and deeply understand it, then you'll be able to write modern C++.

I don't understand what you mean by "write wrappers to use libraries to get the desired behaviour"? What is the relation with RAII?

The other features we've contested are even less native, they're entirely provided by external libraries

?

In my list, only boost are "external libraries" (the standard library isn't external, it's part of the language specification - ok it's still a library, I agree ).
Smart pointer, is an concept resulting from the RAII idiom. The SL provide some but you can write some too if you want, I did some simple ones few months ago.
Template is language feature, OO support is language feature, etc.

I guess it's a semantic thing about where the dividing line is between internal features and external libraries, even if they're provided with the compiler toolset. I know that if I'm writing in C and want e.g. efficient file I/O for large files, streaming, unbuffered reads etc. I would forgo the stdio FILE* and go to the OS layer, so this isn't just an unwillingness to use the C++ std library.

I think we don't talk about the same thing here.

This is a pretty common line about game development studios, it makes me sad because it assumes so much. Games have difficult problems to solve and using a language in "the intended way", whatever that is, may not be the right way to solve them.

This is... I can't find the right word so I'll say "misleading". Games are really complex problems fit together, right, so why make things harder by not using useful abstractions so simple separate each problem and still make the compiler and runtime extract as much juice it can from the hardware? That's the original need C++ is intended to fill. It provides lot of different abstractions because there is a lot of way to represent micro or macro solutions.

As I said, it's more about knowing your tool, it's strengths and weaknesses, than a language problem (today). In our case C++ weaknesses are compilation time, no build system specification, no ABI, not enough good education about it (even today). Strenghs are (very-)high and (very-)low abstractions, allow to combine totally different paradigms (as needed for totally different categories of problems), same or more efficient exploitation of the hardware (assuming the algorithms are efficient too).

So, if you know most of C++ abstractions (ok there are a lot, so it's time consuming), you might solve some problems in a simpler and yet more efficient way than before, and even write it faster than without knowing them.

To me, not taking time to know those tools is like paying a lot of dept to get things quicker. I understand that it's more a short-term strategy than a long term one, so it's fine in a pragmatic way.

Christer Ericson has some thoughts on this which I'd generally agree with, but it boils down to "If you want to ship complex high performance games on console systems, you need to pick and choose your language features carefully and be very aware of what they cost."

I agree too, but it have nothing to do with C++ specific features: if you know those features, their cost and advantages, you can use them exactly when they are useful, not in other cases. C++ have a lot of features so it's often said in those shops that you HAVE TO restrict to some, even if others might solve your specific problem at hands.

It's an educational/knowledge/communication problem.

This is cost in compile time, complexity, transparency, as well as runtime performance and code size. These costs are important and features are never "almost free" - either they have no cost, or they have a cost of which you must be aware. If you're writing a smaller game, maybe you'll never worry about them on PC. If you port it to a 'phone or an embedded platform, maybe you'll need to worry about them then. In my day job I worry about them a lot.

Yes you have to take account of all this, it's the same if you have to consider using other languages.

So, as C++ have tons of abstractions that helps with widely different contexts, and half those features weren't reliable like 10 years ago (when tools weren't even close to the standard), C++ game shops just rely on what they learnt was easy to understand quickly and easy to predict at the time.
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.

4-5 years ago I worked on 4 shipped in the shops Nintendo DS games. I used STL (because we began with no code at all...), template, object orientation, and other maybe obscure features but only where it was very useful to use. Measurements revealed that all the code I worked on was lean on memory and very fast. The main reason is only knowledge of my tools, because other less experienced developers did use most of the same features but didn't always get efficient code. One guy over-used templates to the point his bugs took weeks to fix. One intern abused from object orientation to the point it produced very very slow code. Both were easy to fix if you rewrote them with experience and knowledge of what to use when.

So again, it's an knowledge/educational problem (it's in fact one of the thing that the C++ commitee worry the most about). It depends a lot on your developer's C++ knowledge and experience, and as we already tackle really complexe problems without even considering the language, I assume it's... logical (but not "good") that most (old) C++ shops still have to just use the basics. Even if they only would benefit from learning what is relyable now.

I agree it's better to have a team working without worrying about those features. Yet it's a potential loss of productivity too. Anyway, it's more a company dev-team thing than something that can be really discussed outside of specific contexts.
I wouldn't impose meta programming knowledge on my coworkers if they think it's too hard to understand (I think it can too easily be, even if it's helpful in some contexts).

My take is that most game companies will value pragmatic language proficiency derived from game development experience (either in a job, or on your own) over theoretical language proficiency acquired through formal learning. Courses are good and all, but the making and shipping games (indie or not) with your language is what teaches you the hard lessons. It also gives you something you can show off in interviews or as job application material.

Well I'm not sure what I cited are "over theoritical language proefficiency acquired through formal learning", first because I've used them all in real game (and not game) code with high efficiency and second because I know that C++ features only get into the language if they are proven to be pragmatically useful. I've also found that the only way to write quickly effcicient enough code in C++ is to know and be experienced with what I cited. (like in game jams and with less prototype-kind of game dev.)
Also, I never had any course of C++ (I'm self-made) and only relied on a hard mix of knowledge (books) and practice (tons of projects). I got C++ jobs only because I showed some modern C++ code and had some old demo.


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? 

Maybe then what I'm saying could have more sense to some.
I just wish I could work all day on those games 



Best of luck to you too.


ham and brie : ++, exactly

Paul Eres: the book have been in my amazon list for some years, but I read a lot about about the 'grok' word before starting using it. Actually, I think it's the first time I did. I was originally intending to use it to name a gameplay feature.

Jakman4242 : it always depends on the context. However, if you wish to continue to use C++, you should constantly try to learn more about it and about other languages to get perspective.

[peous]

I don't want to answer to philosophical thoughts about C++ and OOP, just about my experience in writing C++ code for games. In my opinion,

- Use references instead of pointers when you can, prevents a lot of null pointers bugs/ or unnecessary checks
- RAII is a good thing, specially with threading issues, but not used much in other areas
- RTTI and exceptions are mostly not used in C++ games
- stl may be used or not, but it's always good to know it but about collections, the more important is being aware of what is the difference (from a memory point of view) between a list and a vector, a map, a freelist, a lock-free queue... knowing when it reallocs, knowing the speed difference of finding in a map or in a vector... Many prorammers use one container or the other randomly, when performances could suffer so much !

I would say some good experience could also be (not formely part of C++)

- Some good 3d math/classes design
- Memory debugging : This is more related to C if you want, but at the end of every game, you always have some memory corruption problem, or memory allocation/leaks (PS3 does not allow any leak for example)

[Average Software]

Smart pointers are the reason why you can write C++ code for years without never having any memory leak. (don't abuse them though) They don't replace you thinking how to manage your memory, they force you to know object's lifetime rules, with very very simple words (shared, unique, weak).

This I actually disagree with quite strongly.  I write a lot of C++ and Ada code, and I very rarely touch smart pointers for memory management because I very rarely use dynamic memory allocation.  I can do this because I've embraced value semantics.

C++ and Ada are built entirely around value semantics, and too many people only know how to program with reference semantics.  My C++ and Ada types have proper copy constructors/assignment operators whenever possible, and have copying explicitly disabled when not possible.  In the nearly 50000 lines of Ada that make up my current game, I have only 3 or 4 places that need dynamic memory, and a couple of those are actually working around compiler bugs.  This is slightly easier in Ada since it supports value polymorphism and polymorphic copying (allowing heterogeneous containers) but is not unheard of in C++.  In a C++ job I had I wrote a major new module for our program, probably close to 5000 lines of C++, without a single use of the word new.

To me, smart pointers are too often a bandage on a much larger problem, the overuse of dynamic memory.  I think this problem is mostly caused by people trained in languages like Java who think that you have to use new on everything and never really learn the C++ way.  This is why I get nervous around anyone preaching smart pointers.  They have their place, certainly, but in truly well written code they shouldn't even be necessary.  The best way to not leak memory is to not allocate it in the first place.

[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