C++ Lectures

• weak exception safety

• RAII => Object lifetime = resource lifetime
• Resolving ownership solves lifetime problems
• Get the ownership model of the code correct
• unique_ptr
  • easy to reason about
• shared_ptr
  • very hard to reason about
  • good when shared ownership is the correct design
  • read-copy-update [wikipedia]
    • Updater thread
      • should I update the universe?
      • creates an entirely new state
      • sets the new state
    • Worker threads
      • shared pointers to most recent state
      • whichever worker thread is last will free the previous state
    • shared_ptr is not thread safe:
      • one thread writing into it and others reading
      • need to use std::atomic
• const means object isn't modified
• claiming (complete/shared) ownership means that the object is modified
• own
  • direct instance
  • unique_ptr
  • shared_ptr
• never write new, only in factory-only functions
• std::make_shared creates a new object, and sets up the shared pointer
• folly::make_unique

• don't write your own
• folly mpmcqueue, synchronized, futures
• make a different abstraction
• lots of basic primitives
  • std::atomic
    • lockless programming
    • mutexes are too slow
    • major engineering effort
  • volatile
    • doesn't enforce sequential consistency
    • prefer std::atomic bool
    • c uses compiler intrinsics
    • good for hardware directly
  • Locks
    • mutable: internal mutex, internal cache
    • never lock and unlock
    • make synchronization a first class abstraction

• virtual
  • dynamic polymorphism
  • call out to the real classd
• fake virtual
  • implemented with switch statements and enums
• static polymorphism
  • choice is made by the programmer
  • determined by programmer
  • templates
  • overloading
• actual C++ iterators
  • any types that
  • implement =, !, ++, * ,…
• templates
  • good for performance
  • compile times are bad, error messages
  • given a statically polymorphic library, it's easy to make a dynamic version
  • CRTP - curiously recurring template pattern
  • type erasure
• virtual
  • runtime dispatch
  • can be orders of magnitude slower
    • inability to inline
    • dominant cost of using virtual
• std::function: dynamically polymorphic, can't inline
• lambdas are statically polymorphic
• pass lambdas directly
• templates are basically duck typing; will just punch you with a compiler error.

• reference type or a value type?
  • reference
    • polymorphic
    • data is not copyable
• explicit if you are a single argument constructor; allows for implicit conversion from argument to parent type
• never two phase initialize
  • have an init() after construction
  • have a reset() method
• constructors
  • put objects into valid states
  • can't create, then throw
• is it copyable? movable?
  • default to disabling copyable: eg. most RAII types are not copyable
  • expensive to copy; just disable it p
  • sane API - any semantic meaning to copying?
  • most things are movable
  • non-movable: can't be moved to one memory location to another
    • mutexes
• never write your own copy constructor
  • contain horribleness if you really need a copy constructor
• never write your own destructor
  • mainly because you need a resource
  • only for RAII type
  • compose RAII types
• const correctness
• Ok

class Object {

  Object(Object& object) = delete;
}

free function that works on views that do real work wrapper function that allocates memory, resources objects wrap this

containers are one thing, algorithms are another thing