The main problem with learning C first is that you have to understand pointers and const char arrays to do something useful, while in C++ you have to avoid them as much as possible.
I don't recall C++ needing you to avoid pointers and char arrays. Many of us never used the STL, and still don't.
I didn't say C++ needs you to avoid pointers and char arrays, I said you have to avoid them as much as possible. You should not use them until you have no alternative, which is far less common than someone exposed first and too long to C would recognize, which is why it's recommanded to take these languages totally separately as in C++ the important tool you should use in preference order is RAII-based constructs, references, maybe smart pointers (I'm talking about any kind of smart pointer, not just reference counting ones) and sometime (for building abstractions over lower level code or sometimes because it's really the right tool) pointers. Someone thinking in C writing C++ would to to pointers too quickly.
Same thing with raw arrays. Both constructs are just making things too complex to manage, because you have to write tons of code around them to manage them. Knowing when they are useful is not C++ beginners concern in early steps in the language, but it is important in C as they are the main useful abstractions available.
So, really, chose one, and understand that they are really different languages. Then understand that C++ have more useful (but complex) abstractions for you to use, but it cost time to learn each one and more time to really understand them (like inheritance being not a good choice most of the time).
Mixing C way of thinking and C++ way of thinking in the same code, in particular in C++ as it's often said that C is a super set of C++, which is wrong as already pointed, is the best way to make the code impossible to work with later.
I actually learnt a mix of C and C++ initially and was really stuck for years and didn't understand how you could manage to have code that just work, until I started to recommanded read books on C++, which opened my eyes on the fact that I was really doing "C with object". Since then, no problem. The hard part is that it takes more time getting efficient in C++ than in C. But you don't really build the same size of systems with both languages.
Yeah lets also remember that there wasn't even a C++ standard until like 98. I've actually never worked at someplace that used STL let alone boost in their C++ projects.
I don't know that game developers have traditionally been big on it either.
I'm admittedly a C with Classes coder though, and I like to keep classes very flat.
I've only started using the STL lightly in the last two years or so. So far it has worked well enough to not need to be ripped out, but that might change if I started doing more work with custom memory allocators. As to boost, it maybe my C roots, but I really can't stand looking at any of that code and its syntax.
Yeah things have changed. I'll give some data here:
-
http://gamedev.stackexchange.com/questions/268/stl-for-games-yea-or-nay see the most voted answer that sums correctly that STL should be your default toolbox, use other stuffs if you don't have what you need in it (like concurrent containers or very specific performance containers etc.)
- I worked 5 years ago in a company that was very new, we didn't have any engine and we had to make NDS games from nothing, so we used the STL, and we made 6 games published with just STL and custom code;
- In all my recent C++ jobs (game and not) using boost was a requirement, which was helful. Note that it's not a good idea for all development contexts, it's just a sign a lot of companies understand that custom libs are not as good quality as libs that had a lot of expert eyeballs looking at them;
- AFAIK All console developers provide C++ recent compilers with up to date C++03 standard library, sometime with C++11 features (NDS compiler did);
There is also good signs that now compiler writers are more willing to quickly implement the standard instead of their own language extension (Microsoft being always the exception, but at least they provide some features) which means it's easier to write code that works with different compilers and compilers versions than it was around 2000 for example.
That being said, it's understanding that C and C++ are different languages that is key here.
Developer
