I worked through one of his lecture series, I think it was this one but it was a while ago so I'm not 100% sure looking at the link. The focus was on algorithms which is why the "components" in the title is throwing me off a bit.
The series I watched was excellent though! Highly recommended, it's a lot of the same material as his book Elements of Programming but I found it more accessible in the lecture format.
His notes on programming are very well written. I recently stumbled upon them. Reading the rotate and partition sections were real eye-openers! Highly recommended http://stepanovpapers.com/notes.pdf
Yes! Alexander Stepanov is fantastic. He's the designer of the Standard Template Library (STL) for C++, which is C++'s core library of generic algorithms. It's part of the standard libary.
If you can understand how to use the STL properly, you're well on your way to becoming a profiicent C++ programmer.
It's a combination of history and math/algorithms and programming (using C++). If you're just looking for a straight intro to C++ course this isn't it. But it's a ton of fun and the generic programming/STL mindset is very powerful.
Programming Conversations is another great lecture series by Alexander Stepanov:
Sean Parent is very good at getting you in the STL mindset and showing off the expressive power of using the standard STL algorithms in your code. Except in the simplest cases, you should try to use them instead of writing your own loops.
Here are some random tips if you're coming from C or Java:
"new" is not the way to create objects in C++. new and delete should almost never be used by serious programmers in C++. Never use new and delete (or malloc and free). If you want a dynamically-allocated array, use the standard vector.
It's much easier to write C++ than it is to read it. This is because you can always write using a simple clear subset of C++ that you understand. Try to pick a style that you think as many people as possible will understand. Programming languages are for humans to read. I try to write code that I think C programmers can read.
Edit -- Another tip:
Exception safety isn't about C++'s exception-handling language feature. Exceptions still happen in C. There's just not a language feature that directly expresses them.
Writing exception-safe code is nearly impossible in C. RAII and C++'s built-in exceptions make it possible. If you're careful to always use RAII by default, you can get the basic exception safety guarantee automatically without thinking about it. And you can get the strong exception safety guarantee whenever you need it.
> It's much easier to write C++ than it is to read it. This is because you can always write using a simple clear subset of C++ that you understand. Try to pick a style that you think as many people as possible will understand. Programming languages are for humans to read. I try to write code that I think C programmers can read.
While I don't disagree with the sentiment (quite the contrary), if writing code that C programmers can easily read is the goal, using the STL is probably not the best idea.
Personally, while I'm very biased by my usecase for C++ (compute-bound performance sensitive numerical code), I quite enjoy writing code that's essentially C with function overloading, operator overloading and a few judiciously placed templates. I don't miss the STL, OOP, smart pointers and the rest, and the language suddenly seems much more concise and convenient, not to mention compile times are virtually instant and debug builds aren't unusably slow any more. YMMV, of course, everyone should pick the subset of C++ that suits their usecase and relevant constraints.
I agreed. Online lectures don't offer exercises (unless you count pop quizes), books do, and they are pretty intense, varying from level to level. For me, C++ Primer is still relavent, but the thickness and difficulty to start reading the book might cast people off.
Anyway, what are the other better books for C++ that is compact, easy to read while keeping a simple structure?
The OP wasn't asking about just online lectures, it was asking about MOOCs. The best MOOCs I've taken strike a really good balance between lectures, additional reading, and exercises that are automatically graded.
A lot of books don't have any exercises, and the vast majority of the ones that do have no method of verifying it was done correctly.
So maybe today the best C++ book is better than the best C++ MOOC today, I've no doubt that a MOOC could be designed far better than any book could ever be. And I'd bet that's exactly what the OP was trying to find.
I spent a long time with C++ and my learning was primarily through books. However, I also think that not everyone learns best by reading. Some learn better by listening, some by doing and some by observing others do something. For someone of such disposition, it might be more beneficial to follow a MOOC than to solely study the subject from a book.
And a good article it is. I've never been a great believer in learning styles, but I do know that for me, it's far, far more convenient to watch a video and read a smaller amount of text than to have to solely read a book.
I read text all day. Watching a video is novel and exciting, and I think I tend to pay more attention because of it. But that's just anecdotal. Grinds my gears when people suggest that "books are the best way to learn" any kind of programming language.
It cover very smoothly most of the main C++11/14 features, while explaining the pros and cons and the inner choices that has been made when those said feature were implemented
Can't tell with which one to start, especially for modern C++14/17. But after a couple (or maybe one) of beginner's books, I'd recommend to dive into Bjarne's TC++PL book.
The CppCon videos [1] are a great resource, but you'll have to thread your way through the wide variety of topics.
The videos from Herb Sutter [2] will usually emphasize best practices and give great examples, although he expects the audience to have a good bit of familiarity in regards to 'modern' c++ elements (C++11 and beyond).
I initially disliked this also, but then I realized this is a natural extension of just programming generically almost all the time. You use the language to manage flow between types and to define types, but the types themselves aren't "binding" in a sense. If you use auto all the time but don't use templates, type deduction, and automatic type conversion, you're missing out on much of the language.
Auto forces you to think about the general relationships between types. In a sense, it really brings all of the elements of the language together.
In my example although auto was used, it was explicitly specified in the trailing return type that the function returned an int. This makes auto both needless and confusing in this instance, and should hardly be a recommendation!
You are right about the joys of auto with regard to template types and deduction but the implicit type conversion in C++ is a big danger; far better to be explicit about what a function is returning for the most part due to your inability to constrain the implicit conversions; it also helps with maintainability as you can read through small portions of a giant codebase without having to have a holistic overview of the entire system - you can treat each section in isolation because it is explicit in what it is returning, so you can make decisions as a maintainer based on the explicit information in front of you instead of the "it might be this or it might be that" scenario that auto (as a return type) offers.
(I'm not saying auto is bad, but should be used with caution for the return type of a function as it makes the code impossible to understand without an IDE - from looking at a diff between two files, how do I know what it is doing or make a fix under pressure?)
Auto when used as a shortening of lengthy template iterator variables, then yes I heartily welcome them.
There is no maintainability problem if the general behavior is correct for all types that a statement can be composed of. You don't need an IDE, you just need a decent operating model of the nature of interactions between types.
It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful.
If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.
Yes, auto is definitely welcomed in the case of my::long::scoped::namespace::templatedItem<more::details::here>::const_iterator but using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left.
Of course, in the case of types that are the results of other templated types e.g. T,U -> V then it makes sense and it is obviously welcomed in the syntax of lambdas (far more sensible to me than the C# syntax or C#'s Func) but the use of it everywhere seems foolish.
If it were a good idea, then we would be pushing to remove the return type being at the beginning of a function at all; please say this isn't the case!
eg.
main(int arg, char* argv[]) -> int
or complete stupidity that makes it impossible to read without an IDE (e.g. in a diffing tool):
auto main(auto arg, auto* argv[])
When it turns into that, I'm quitting the industry.
> using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left
This is not what auto as a function return type is for. Auto wasn't invented so people could put int on the right side of a function.
There are two reasons to use it. The first is similar to using auto for a long type name. You can use decltype to declare the return type to be the same as the resulting type of an expression. The second is what you mentioned, keeping in mind that you can use template types in the decltype expression.
I look it as a good experiment to find the right amount of auto to use. Go to one extreme and then see what bites you in practise, then make changes to where you use auto so that you get good and clean code.
Yes, I think auto for iterators is good but for return types it doesn't help any poor developer left to maintain your code in 20 years time (even 2 years).
Dealing with an extensive large and complex 5 million line C++ codebase at the moment where many of the original developers have left leaving zero documentation, design documents or specs, or even sensible comments, I truly increasingly cherish readability and understandability of any small portion of code without having to get a holistic overview;
I should be able to understand what it's doing in isolation - auto as a return type or as a deduced return type doesn't help me see what something is doing from the calling site without having to wade through reams of other function calls or step into them; I think time will not be kind to it if overused.
A good rule to follow would be that whenever auto is used the type that it would otherwise be has to be present in the statement, or that it's an iterator. That results in still seeing what type you have but not having to repeat yourself.
I watched part of Udacity's "C++ for Programmers" course and was surprisingly unimpressed - their content is typically great (in my experience, like with their 3D graphics course). Udemy looks like they have some good courses - haven't tried them myself.
Honestly, I have had success with reading Stroustrup's book and doing the exercises. YMMV.
Having gone through most of Udacity's "C++ for Programmers," I agree with you. I don't feel like the exercises were helpful at all a lot of the instructions were outdated and didn't match with the content.
I only looked at one: C++ for C programmers on coursera. It was helpful to get up to speed with the STL and the new features in C++11. Some of the programming assignments included implementing the min max algorithm and using Monte Carlo.
I would be very wary of any Google material on C++.
Their C++ style has a heavy emphasis on pointers. In addition, their banning of exceptions warps their code in other ways (for example a heavy use of out parameters).
Also, they have a tendency to use their own alternatives to stuff in the standard library.
If you already know modern C++ you can discern the good advice from the bad/archaic advice, but if you are learning Modern C++, you would be best served by avoiding it.
Agreed! The Google style guideline goes out of its way to inform people not to use templates too much, or something along those lines. It hints that those features are for language experts. This is bad advice, in my opinion and basically keeps you out of using the most useful features of the languages.
Sure, but do you know them? If you don't, how will you judge if their reasons are valid for you?
In any case, the simple fact that the reasons are unknown speaks pretty heavily for the case that the reasons aren't universally valid, so you would be learning a dialect of C++.
Google documented pros/cons and reasons for their decisions in their style guide, which is public [1]. Whether or not Google's final decision is applicable to you, reading the pros and cons is informative. For example, their reason for not using exceptions is specific to their existing code base [2], but the discussion is informative.
Yes, the style guide is informative and Google does have reasons for doing things the way they do. However, they way they are doing things is decidedly not embracing Modern C++. Their teaching material will reflect their philosophy. Therefore, when you are learning modern C++, you should avoid their material. After you are comfortable with Modern C++, then you will have the perspective to differentiate the good advice applicable to you.
Another great, and free place to get C++ tutorials is the Virtual Studio software websites. As long as you aren't afraid of reading your lesson, there is a ton of coverage from simple tasks, ranging all the way to super advanced. For me reading is a little less convenient because you... have to read, but it's also more convenient because it's at your own pace without have to hit the pause button while you follow along with a video and try to code at the same time.
https://www.besanttechnologies.com/training-courses/data-war...
IRC was the best online course you could have had back in early 2000s, provided you could come up with the right questions, read the right books and did your own research first.
In my experience yeah. And even still in the past decade. People on IRC want to sharpen their chops and keep their skills fresh, and if you’re respectful and doing most of the learning in your own, they’ll usually be glad to give feedback or suggestions, or even help you understand difficult topics. It’s mutually beneficial to all involved, even lurkers can benefit a lot from it. Hugely underrated resource. I’m not sure if the same culture is there in slack though, but plenty of people still use IRC to socialize and learn and teach.
The problem is; you could listen to two half hour videos on templates and still get stuck on a simple problem like how to use a templated member type or how/where to define a templated member function.
https://www.youtube.com/watch?v=aIHAEYyoTUc&list=PLHxtyCq_WD...