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.