I guess I'm going to go ahead and be "that guy".

Don't aim to work with a specific language.

I feel you should reframe your goal to be a "problem solver" that knows how to pick and use various tools to solve a problem. C++ may be one of those tools. Maybe C. Maybe Python. Maybe Java. You want to develop your skill set to be flexible enough to adopt the right tool for a job. Now, that's not to say you can't be a language expert. Language experts are very valuable and becoming one is a perfectly reasonable goal. That said, I think you'll find that you have many more opportunities when you remain flexible.

With that out of the way, I would say good next steps for continued C++ mastery are to read and understand Scott Meyers' excellent books:

• Effective C++
  
• More Effective C++
  
• Effective STL
  
• Effective Modern C++
  
  Also go through the CppCoreGuidelines.
  
  Beyond the language, make sure you know your standard data structures and algorithms.

There is also "Effective STL" if you're a big STL user.

Basic:

C++ Primer

Effective C++

Effective STL





Advanced:

More Effective C++

C++ Coding Standards: 101 Rules

C++ Templates The Complete Guide

Large Scale C++ Design

If you're serious about C++ programming and using the STL intelligently, I highly recommend getting a copy of Scott Meyers' Effective STL. He discusses exactly what you're asking about, e.g. when is a std::list better (or worse) than a std::vector, or how is a std::vector<bool> different than a std::bitset.

Actually all three of his books (Effective C++ and More Effective C++) are great reading if you haven't done so.

As for your question, if you need a thing to hold an array of something, std::vector is usually the go-to container for that.

The correct answer to:

Q. Should I learn C or C++ first?

Is:

A. Yes.

WARNING: Highly Opinionated Analysis of C vs C++

I see a lot of people recommending one way but no one offering an analysis of BOTH the Pro's & Con's.

I've been using C++ since ~1990. I've briefly worked on a PS3 C++ compiler when I worked for Sony. I've seen 2 major problems over the years with C++ programmers:

1. People don't exercise discipline and restraint in K.I.S.S.

They use (and abuse) every language feature because they can. There is this tendency to over-engineer even the simplest things. Take a look at this complete clusterfuck of CRC in the Boost library.

1109 lines of over-engineered C++ crap for a simple CRC32 function instead of a mere 25 lines of code!?!?! The C version would:

• do the same thing,
  
• be simpler to write, and
  
• be simpler to debug, and
  
• more importantly solve the problem at hand, not abstracted to the point of being over-engineered.
  
  The trade-off would be is that it is less flexible, but WHEN was the last time you needed to use a custom CRC polynomial!?!? One would instead use a different algorithm such as MD5, SHA, etc. that:
  
  
• has better better error-rate detection,
  
• less collisions,
  
• is multi-core.
  
  This excellent SO on hashing is but one example of focusing on the big picture.
  
  2. People lack a basic understanding of the cost let alone the implementation of C++ expressions.
  
  I've seen people stick a virtual function inside an inner loop and wonder why their performance is crap. I've seen people fail to grasp a basic understanding of pointers. I've seen people not understand memory management and how to guarantee zero memory leaks. I've seen people spend more time on writing an "über" template and waste hours debugging that instead of just writing something in 1/10 of the time and move on.
  
  IMO, due to the bloated, over-excessive verbose nature of C++ it is for these reason that I strongly recommend a beginner learn C first and then learn C++. You'll have a better understanding of why C++ is designed the way it is, what the design trade-offs are/were, what C++ hacks are, and how to best use the languages to their potential.
  
  However, this is ignoring the benefits and disadvantages of the Pro's/Con's of why one would learn C++ or C first.
  
  

  Learn C++ first
  

  
  

• C++ Pro
  
• C++ really is a better C then C in so many ways, too numerous to enumerate
  
• In the ways it is worse the smart people / companies use a sub-set of the language: Ubisoft avoid Templates, Exception Handling, and Run-Time Type Identification. When even a C++ committee member admits he writes in a sub-set of C++ himself you know the language is b-l-o-a-t-e-d.
  
• You won't have to unlearn certain "bad habits" of C
  
• Your skills will up-to-date
  
• Your code will be textually smaller (See note about Con)
  
• Job Security -- that is half joking, half serious. Seriously.
  
• You can enjoy the time exploring the different nooks and crannies of the language. You will see a different way to solve the same old problems. This can be both good and bad.
  
• Eventually you'll be able to enjoy deep technical C++ comedy such as Hitler on C++
  
• OOP (Object Orientated Programming) makes it almost easy to quickly write bigger scale programs
  
• Is multi-paradigm: Procedural, OOP, Functional, Generic. You have the freedom to pick and choose the parts of the language that fits your needs.
  
• For every problem you're trying to solve there is probably language support. Threads, and Atomics are finally part of the language.
  
  
• C++ Con
  
• You won't understand some of the C idioms used in practice
  
• The language is HUGE -- it will take you a decade to properly learn the language
  
• Debugging C++ is a PITA
  
• While people write crap code in any language, it is harder to read bad C++ code then C code.
  
• Compiler Support for the latest standards is a constantly moving target. Translation: Microsoft's Visual C++ has traditionally had crap support for the latest C and C++ standards. The good news is that MSVC 2015 finally supports a nice section of the language.
  
• While C++ can be textually smaller, one's code can easily be "bloated" if not careful (such as templates and partial template specialization)
  
• You really won't understand the run-time costs, nor be motivated to understand the underlying assembly language generated, by a "simple" C++ expression.
  
• Expect L-O-N-G compile times for any significant code base unless you use a "Bulk / Unity" build (you compile one .cpp file that includes EVERYTHING)
  
• It will be hard to resist over-engineering, over-complicating even the most basic tasks
  
• iostreams is a complete clusterfuck. Even the C++ committee recognizes there are many problems with C++ iostreams but sadly nothing is being done towards performance at the cost of type safety.
  
• It is far easier to blow your cache. Even Bjarne Stroustrup, the language designer, until 2012 didn't have a clue in understanding why Doubly Linked Lists were so slow compared to Arrays. HINT: The L1 Cache usage is critical for performance sensitive code.
  
• People tend to over-use the OOP paradigm even when they shouldn't. People make dogma and religion of "Design Patterns", failing to think if the model applies or not.
  
• The OOP paradigm is slow and bloated compared to Data-Orientated-Design. See Sony's Pitfalls of Object Orientated Programming
  
• Reflection STILL isn't standardized -- everyone has their own "home grown" approach. Maybe in C++17 ?
  
  
  

  Learn C first
  

  
  

• C Pro
  
• The language is tiny and easy to learn. Learn C the Hard Way is a great tutorial.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• You will have a better understanding of the run-time "cost" or performance of code instead of a single line hiding "hidden" behaviour.
  
• You'll be a better programmer for understanding more of the lower-level implementation. If you don't know how to write itoa() or atoi() you're a noob programmer.
  
• You'll be forced to keep things simple
  
• You'll understand how to implement OOP in a non-OOP-native language, and better appreciate C++'s syntax sugar of OOP.
  
• You'll appreciate how C++ templates solve some but not all "textual replacement" problems and why #define macro's suck for debugging.
  
• Is ubiquitous, runs everywhere, and easy to get a C compiler for everything under the sun. Matz's Ruby Interpreter (MRI) was written in C, the Java VM was originally implemented in C, Perl is implemented in C, Linux is written in C. Anything popular and older then 10 years was probably written in C.
  
• Variables must be placed at top of a brace {
  
  
• C Con
  
• Compared to C++, you'll hate how primitive the language is such as typedefs for structs, no local functions, const is only "half" useful in C -- it can't be used in array declarations (See: http://stackoverflow.com/questions/5248571/is-there-const-in-c ), etc.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• Simple algorithms can be tedious to write
  
• Variables must be placed at top of a brace {
  
  With that said there are numerous C++ books I would recommend to ALL C++ programmers. They are sorted from beginner to expert:
  
  
• The Design and Evolution of C++, Bjarne Stroustrup -- another ancient but fundamental to understanding all the kludges in C++
  
• The C++ Programming Language, 4th Edition <-- "Mandatory"
  
• ALL the books by Scott Meyer
  
• Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
  
• Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library -- ancient but good
  
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu -- another ancient but it blew the doors open for C++ Meta-Programming. IT is interesting that he hates C++ -- he now works on the D language.
  
  If you can get only one book, get the The C++ Programming Language.
  
  Even though Bruce's book is ancient he keeps it simple and is a fun easy read. Remember this is before C++98 where the language is much simpler.
  
  
• Thinking in C++, Bruce Eckel
  
  You can find it online for free
  
  Lastly, just because you can, doesn't imply you should. Use balanced C++ and you'll be fine.

If you haven't read these books already, what are you doing, go and read them now.

Effective C++

More Effective C++


Effective STL


Effective Modern C++

Effective C++
More Effective C++
and Effective STL

These are books I read many years ago, they can be helpful but may be dated and will not include newer features. But as an introduction they worked well.

Thinking in C++ Voume 1 and 2 by Bruce Eckel

https://www.amazon.com/Thinking-Vol-Introduction-Standard-2nd/dp/0139798099/ref=dp_ob_title_bk

https://www.amazon.com/Thinking-C-2-Practical-Programming/dp/0130353132/ref=pd_sbs_14_1

And Scott Meyers

Effective C++ - https://www.amazon.com/Effective-Specific-Improve-Programs-Designs/dp/0321334876/ref=pd_sbs_14_2

Effective STL - https://www.amazon.com/Effective-STL-Specific-Standard-Template/dp/0201749629

The assembly is rather light at the beginning. In your first year you have to write some assembly to control a little car with infrared sensors, but it's really easy. Later on though, there are pretty interesting classes on assembly which are pre-reqs for classes on optimizing/debugging. Also it never hurts to learn more. But this definitely isn't something I'd be too worried about coming in.

After K.N. King's book, we don't really cover many more C books. But Kernighan and Ritchie's C Programming Language is a good thing to read.

In terms of C++ books we cover, it's a little weird. For one class, we needed C++ Primer and another we needed C++ Primer Plus. We've also needed Algorithms in C++ by Robert Sedgewick and a couple others. However, most of our classes don't have "required" textbooks, just recommended ones. If you send me a message I can compile a list of the recommended ones from my courses this far.

Personally, I'd highly recommend all of Scott Meyers' books, such as Effective C++, More Effective C++, and Effective STL.

This kind of stuff is available in painful detail in Josuttis' book, but there is a fair bit of "other stuff" in there.

That said, better than the fish book for someone who wants just the good stuff would be Effective STL and/or Standard C++ IOStreams & Locales.

Not a tutorial but a book. It's a bit dated now as it was released far before C++11, but still a good reference.

http://www.amazon.com/Effective-STL-Specific-Standard-Template/dp/0201749629

> STL != standard library

Oh come on. You know as well as I that STL isn’t even a term in the standard and that, although they are historically different, they are often used interchangeably even by C++ gurus (such as /u/stl and Scott Meyers). And that was clearly not the point of /u/ErstwhileRockstar (nor, I suspect, of /u/mitsuhiko).

> even some "old but gold" ones are fine

The Scott Meyers book you mentioned, Effective C++, is just that: old but gold.

I'd also suggest you read his other books, Effective STL and More Effective C++.

These 3 books stand out amongst many for me, for their accessibility and effectiveness. It is worthwhile reading them now and getting a solid understanding on pre C++11 design principles etc.

Once his Effective C++11 book comes out, read that too!

Following these, but now moving from intermediate to expert level, the single biggest influence on how I designed and wrote C++ was Modern C++ Design by Andrei Alexandrescu.

It's pre C++11, but the insights into generic algorithm design using templates are just incredible.

Excerpt from the description on Amazon:

> Alexandrescu offers a cutting-edge approach to software design that unites design patterns, generic programming, and C++, enabling programmers to achieve expressive, flexible, and highly reusable code.

If there is ever one book I recommend people to read, it's this one.