1. initialization lists
   1. The order in which the list entries are set down is determined by the declaration order of the members within the class declaration, not the order within the initialization list
   2. used in 4 case 1.When initializing a reference member 2.When initializing a const member 3.When invoking a base or member class constructor with a set of arguments 4.When you want to avoid creating un necessary temp objects.
      1. Topic
   3. EXCEPTION: Yes, to facilitate argument screening.
2. templates
   1. Note also that unlike class type declarations, the keyword struct cannot be used in place of typename when declaring type parameters.
   2. if the template 'definition' is included in a header file its called 'inclusion method'
   3. Class Templates
      1. only members that are used are instantiated.
      2. we need to specify the TYPE of the class as a declaration. unlike in just function templates.
      3. Specialization
         1. partial
            1. any number of parameters / arguments can be specialised.
            2. only the MOST specialised funciton is picked. If nothing is found then onlly a template class is instantiated to fulful the request.
         2. full
            1. you don't give any typename jsut the actual type example template <> class MyClass (int)
      4. If we have more than one template parameter in the class definition. EACH member def should also have BOTH the parameters. ex: template <typename T, typename CONTAINER = vector<T> > class Stack { private: CONT container; public: T pop(); ... }; template <typename T, typename CONT> T Stack<T,CONT>::pop () { ... }
3. const correctness
   1. members
      1. "whenever the member function wants to guarantee that it won't make any observable changes to its this object.
   2. Mutable
      1. Allows a const funciton to change a non observant member variable.
4. STL
5. c++ Exception
   1. 4 alternatives upon detecting a problem
      1. terminate the program
      2. return a value representing "error"
      3. return a legal value and leave the program in an illegal state
      4. call a function supplied to be called in case of "error"
   2. Alternative views of exceptions
      1. Designed to support error handling and other exceptional conditions
      2. Designed to handle only synchronous exceptions
      3. Asynchronous exceptions should be handled in other way, such as signal, etc. which may be system-dependent
      4. The exception-handling mechanism is a nonlocal control structure based on stack unwinding
   3. An exception is an object of some class representing an exceptional occurrence
   4. Resource management
      1. Exception and new
      2. Resource Exhaustion
      3. auto_ptr
         1. Pitfalls of auto_ptr
            1. Never let auto_ptr point to static or global object
            2. Never let two auto_ptrs point to the same object
            3. Never let auto_ptr point to array
            4. Never store auto_ptr in containers
      4. Use constructors and destructors
      5. Exceptions in Constructors
      6. Exceptions and Member Initializations
      7. Exceptions and Copying
   5. Exceptions that are not errors
   6. Don't interrupt me while I'm interrupting
   7. Exception Specifications
      1. Checking Exception Specifications
         1. A virtual function may be overridden by a function that has an exception-specification at least as restrictive as its own exception-specification
      2. Empty exception specifications could help to improve performance
   8. Exception and Efficiency
      1. Overhead of Exception
         1. try block
         2. catch clause
         3. Cleanup of handled exceptions
         4. Automatic and temporary objects with non-trival destructors
         5. Constructions of objects with non-trival destructors
         6. throw expression
         7. Enforcing expression specification
         8. operator new
      2. Two approaches
         1. Code approach
         2. Table approach
   9. Error-Handling Alternatives
   10. Standard Exceptions
       1. bad_alloc
       2. bad_cast
       3. bad_typeid
       4. bad_exception
       5. out_of_range
       6. invalid_argument
       7. overflow_error
       8. ios_base::failure
   11. Standard-Library Exception Safety
   12. Destructor should never throw exceptions
6. Distructor
   1. The destructor automatically calls the destructors for all member objects and all immediate nonvirtual base classes. First, the destructor's body ({...}) is executed, then the destructors for member objects are called in the reverse order that the member objects appear in the class body, then the destructors for immediate base classes are called (in the reverse order they appear in the class declaration). Virtual base classes are special—their destructors are called at the end of the most derived class's destructor (only).