"The Essence of C++" - from the horse's mouth

I recently came across this lecture by Bjarne Stroustrup called The Essence of C++ that he gave in 2014 at the University of Edinburgh. Although it's 7 years old and there seem to have been more recent talks by Bjarne along similar lines, I still thought there were several important learnings here which would prove to be timeless. Plus, I love such "meta" talks where we get to know more reasoning and intuition about a feature instead of just its syntactic or performance details.

So here are my notes for the lecture that I'm pretty sure I'd want to come back to in the future :

1. Software lives longer than hardware, usually.

2. What all things did he want in the language?

   1. Type safety - don't want to mix incompatible types

   2. Resource safety - don't want to leak any resources

   3. Performance - want to be able to do things as fast as possible

   4. Predictability - operations should be completed in a deterministic duration of time. This excludes operations like malloc() which suffer from unpredictability due to issues like fragmentation and memory leaks. This is why dynamic memory allocation is not used in mission-criticial / life-critical systems as explained here. Instead, we rely upon stack-based allocators, memory pools or 3rd-party memory management libraries.

   5. Teachability - it should be easy to teach and learn

   6. Readability - it should be easy to read by people and machines

3. Target domains for C++ include systems programming, embedded systems, resource constrained systems etc. A phrase that stuck with me here - "C++ is expert friendly".

4. Inspiration for C++ came from two programming languages - C and Simula.

   1. From C, we borrowed a resource model which allows us to map instructions and data directly to hardware. e.g. some struct is going to take exactly 5 bytes in memory.

   2. From Simula, we borrowed concepts of classes and hierarchies (along with associated keywords like constructor, destructor, virtual etc) which allow people to make their own abstractions. This is important as some languages before this were based on certain abstractions made by the language designers themselves.

5. We want the language features to do their own resource management. e.g. STL containers release their memory once they go out of scope; last shared_ptr owner frees up memory of the shared object etc.

6. How to cheaply return from a function?

   1. Objective : return the sum of two matrices from a function - Matrix add(const Matrix& mat1, const Matrix& mat2)

   2. Bad options :

      1. raw pointers - no clear rules about ownership of memory

      2. references - we don't want to return reference of a temp object and even if we were to return reference to an object allocated on the heap, there'd be ownership issues similar to raw pointers

      3. by value - matrix could be very large so we don't want to pay the price of copying it

      4. passing pointer / reference of the destination matrix - makes the function signature look unpleasant

   3. Good option : use move semantics!

7. Garbage collection is not general (used for memory but not for other resources) and not ideal (we'd be imposing some extra cost of maintaining metadata, e.g. count of owners which share an object, which may be an overkill). So we should apply these techniques in order :

   1. Use automatic resource management of containers like std::vector etc when they go out of scope.

   2. Use RAII to manage all resource handles along with move semantics.

   3. Use smart pointers for cases like if we want to return the base pointer which is acting as a reference to a derived class or when ownership is shared.

8. Virtual functions carry an extra cost compared to ordinary function due to their calling mechanism and also don't inline well.

9. Generic programming

   1. 1st attempt (1980) : macros but there were too simplistic (not type-aware for instance)

   2. 2nd attempt (1987)

      1. Aim was to have zero overhead on top of C-arrays (e.g. std::vector is a very thin wrapper over C-array) and support interface checking.

      2. Templates - allow compile-time duck-typing i.e. as long as a template argument has all the members as required per the template function / class body, compilation succeeds.

10. Concepts (C++14) allow us to have predicates on template parameters so are better than duck-typing.

11. Using modern C++ improves efficiency & safety while usually maintaining the performance. e.g. unique_ptr v/s raw pointer.

Also added A Tour of C++ to my to-read list!