Ask HN: What is the best Modern C++ MOOC? | Hacker News Reader

Ask HN: What is the best Modern C++ MOOC?

228 pointssenatorobama50 comments

I am thinking about going through the below course from Alexander Stepanov at Amazon A9. Anyone has experience with this course.

https://www.youtube.com/watch?v=aIHAEYyoTUc&list=PLHxtyCq_WD...

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.

There is a 4 part series by him on algorithms too.

https://www.youtube.com/user/A9Videos/playlists

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.

His books are fantastic too.

Elements of Programming:

https://www.amazon.com/Elements-Programming-Alexander-Stepan...

and From Mathematics to Generic Programming:

https://www.amazon.com/Mathematics-Generic-Programming-Alexa...

If you prefer video lectures, his second book is based off his lecture series Four (three) Algorithmic Journeys:

https://www.youtube.com/playlist?list=PLHxtyCq_WDLV5N5zUCBCD...

https://www.youtube.com/playlist?list=PLHxtyCq_WDLW0NqZCcrrQ...

https://www.youtube.com/playlist?list=PLHxtyCq_WDLXrHwcaay14...

https://www.youtube.com/playlist?list=PLHxtyCq_WDLVQPzEm3igP...

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:

https://www.youtube.com/playlist?list=PLHxtyCq_WDLXFAEA-lYoR...

I would also recommend searching YouTube for videos by Sean Parent. This one in particular is very enlightening:

https://www.youtube.com/watch?v=qH6sSOr-yk8

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.

Good luck!

> 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.

Not familiar with the course but I’m a big fan of him, he’s a beast.

As a long-time C++ dev, I don't think a video/lectures is a good format for learning it. I'd suggest to read books.

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?

>Online lectures don't offer exercises

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.

I literally just finished reading an article on how the myth of learning styles keeps getting debunked - https://www.theatlantic.com/science/archive/2018/04/the-myth...

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.

Which ?

"Effective Modern C++" is extremely well written (https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...)

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

Highly recommended book by the community

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).

[1] https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg

[2] https://herbsutter.com/

Herb Sutter is very good. His "almost always auto" idea is crazy though - who on earth thinks this is a good idea instead of being explicit??

auto main(int argc, char* argv[]) -> int

Madness!

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.

Note that "the right amount" depends not just on your personal taste, but also on the experience level of others who use your code.

Is auto in C++ the same as auto in D?

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 strongly prefer text over video[1], and the best book on modern C++ is "Effective Modern C++" by Scott Meyers: https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...

[1] I wish people invested more time/effort in writing good textbooks instead of videos/MOOCs.

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.

Great.. this should help me transition from an embedded C role to a C++ role which is the natural transition.

Curious why you want to move from embedded to non-embedded? Do you have a traditional CS background or more of a EE?

Google has some C++ content. It's on my to-do list right now

https://developers.google.com/edu/c++/

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.

That is the mistake I made in the 90s. I thought I was learning C++ but really I was learning MFC.

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.

I think fundamental understanding of pointers is important to C++ and not we’ll understood by many people who come from a non-C/C++ background.

Typically, I would agree. Yet, I'm fairly certain Google has good reason for doing so.

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++.

> Sure, but do you know them?

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.

[1] https://google.github.io/styleguide/cppguide.html

[2] https://google.github.io/styleguide/cppguide.html#Exceptions

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.

Maybe this is still the case?

Do you mean you read a book and then asked people when you got stuck?

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.

MITOCW has C++ courses. Not sure about Modern,tho

Reply on news.ycombinator.com