C++ as a second language (Chrome University 2019)

Показать описание

A tour of C++ for experienced programmers coming from other languages, including Python, Java, JS, Ruby, JS and Golang.

In this talk, Chris Blume (a.k.a. ProgramMax) covers C++11 features, templates, include & linkage, RAII, destructors & scope, pass-by-value / -reference, smart pointers, and more.

Welcome to Chrome University, where you will learn the foundations of how Chrome works.

Links:

Рекомендации по теме

Комментарии

Great refresher of C++ as it's my main language that I'm purely self-taught in. What I like about the video is how you show the equivalent comparisons and the subtle differences between different languages.

skilz

It's great to see a video neither too short nor too long - just enough for me to digest.

xiaolu

I have more than 5 years working with Cpp and I can tell that this explanation was very clean and objective. Thank you.

nunofigueira

I like Mr. Blume's videos. I have been programming in C since 1982 (before the author was born) and C++ since 1989. These are my thoughts.
a) Header files for "*.c" files should be "*.h" and for "*.cpp" files should be "*.hpp". The exception being C++ source that has only functions in the header and the header has extern "C" surrounding the calls. Those C++ headers do end in ".h". This indicates that the code can be called and linked into C programs, even though the code is C++. Why do that? To call your C++ code from Java using JNI (used when writing Android apps).
b) When using macros to prevent double inclusion of headers, the ending macro line at the bottom of the header should be formatted as "#endif // MUSICTYPE_H". Whenever you make a macro and the end is more than two lines away, add a trailing comment to the macro to indicate what it is terminating. That way you and others studying the code have an easier time figuring out what is going on.
c) Destructors are super important! Let's say you are going to do something in your class that needs cleanup, for instance memory allocation. These are the steps: add a pointer to the class, set the pointer to NULL in the constructor, then delete the pointer in the destructor. Now you can go allocate. Never allocate before writing the cleanup code, that is how you forget and get leaks. Discipline is better than garbage collection. Garbage collection is better if you don't have discipline.
d) RAII. I think what the author was saying was don't do anything that can fail in the constructor. Just do initializations.
e) Everything is easy with raw pointers while references are problematic. References were created under the false belief that C++ programmers can't understand raw pointers. But classes are far more complex than raw pointers. References have introduced a host of problems while raw pointers offer unlimited power. Don't be afraid of -->, it looks better than a dot. C++ programmers think in both classes and pointers.
f) I started programming in C before the standard library so I wrote all my functions, which still work on every computing platform to this day. When the standard library came out in the mid 1980s I studied them and said these calls are dangerous and have no protections, use them if you want an unstable program that will be prone to crashing.
g) You can do everything with C++98. Newer versions allow you to do what you can already do in different ways, at the expense of portability.

drwisdom

Nice and concise talk. I have only remark though and it is something you see from other lecturers in C++ talks and it has to do with shared_ptr. It is the, if you use it you might have thought things wrong mentality. And this mentality comes purely from the obsession, specifically in C++ world, with speed. First, in almost every other language (including Objective C) complex objects are always dynamically allocated in the heap and are reference counted. Second, there are certain cases - and they pretty common - where you have to use shared_ptr. Like for example when exposing a complex object class member through a getter. Which is common thing in case of graphs of related object models, e.g. database entity relationships. Third, shared_ptr is a generalized abstraction of what string and vector and every other container does. They wrap and manage a pointer to a dynamically allocated memory in the heap. So no lets not demonize shared_ptr but instead explain what it does and when we should use it. </long_comment>

dimitriosmenounos

Excellent video. Seems way less popular than it should be.

HarshPrateekSingh

will there be a full course available ?

aovchinn

I never have that much trouble with pointers and I've worked on large and small projects. I mean yes they can trip you up and crash your program but it's not like it's hellfire and brimstone, I occasionally run into issues with pointers but I could never be more grateful for them. They simplify so much of my program and make things so much easier I wouldn't have it any other way. You can do so much with pointers it's not even funny the level of magic you can do with them. Why are people taught to fear them? Yes if you act stupid with pointers then sure but that's not the pointers fault, that's the programmers fault. If you structure you program carefully as any programmer should do you really shouldn't have too many problems out of them outside of the occasional screwup which is inevitable with anything.

junehanabi