1. 2

Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/cppcon/cppcon2015

To this day most people who set out to help others learn C++ start with “introduction to C” material. I think this actively contributes to bad C++ code in the world. For the past few years I’ve been teaching C++ (and making suggestions to folks who intend to teach themselves) in an entirely different way. No char* strings, no strlen, strcmp, strcpy, no printf, and no [] arrays. Pointers introduced very late. References before pointers, and polymorphism with references rather than with pointers. Smart pointers as the default pointer with raw pointers (whether from new or &) reserved for times they’re needed. Drawing on the Standard Library sooner rather than later, and writing modern C++ from lesson 1.


  2. 1

    This approach reminds me of “language levels”: if want to teach a subset of a language, it’s helpful if the tooling doesn’t reveal features before you’re ready to teach them. You don’t want autocomplete or error messages to suggest features you haven’t taught yet.

    In C++, is it possible to set compiler flags to ban certain language features? I know some workplaces ban exceptions; could you go further by banning pointer arithmetic in your application code? Maybe this is hard because without a module system, the boundary between your libraries and your application is fuzzy?

    1. 2

      It sounds as if the subset being taught is very close to the C++ Core Guidelines. There are static analysers that check a bunch of those rules (including now new, no raw pointers, which implicitly means no pointer arithmetic), but they may not prevent you using operator::[] instead of .at() on a std::vector, for example, which implicitly does unchecked pointer arithmetic. I’m not aware of any compilers that have them integrated, but some IDEs do.