Effective c++notes

1,320 views

Published on

Notes on book 'Effective C++'

Published in: Software, Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,320
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Effective c++notes

  1. 1. U T T A M G A N D H I S Y N E R Z I P H T T P : / / W W W . L I N K E D I N . C O M / P U B / U T T A M - G A N D H I / 2 1 / 7 A A / 2 4 Effective C++
  2. 2. —— Acknowledgments —  This presentation is based on Scott Meyers well known book ‘Effective C++’ —  http://www.amazon.com/Effective-Specific- Improve-Programs-Designs/dp/0321334876
  3. 3. Variable Declaration —  Delay as far as possible ¡  can avoid construction and destruction, ¡  keeps the context in which it is required ¡  for loop construction, consider creating in loop based on cost of assignment v/s cost of construct destructor
  4. 4. Passing of Parameters —  Pass by value ¡  Primitive types ¡  STL function objects, iterators —  Pass by reference ¡  User defined objects ÷  Efficient than pass by value ÷  No slicing —  Return by reference ¡  Local data should not be returned by reference
  5. 5. const 1/2 —  Replacing #define with const ¡  Reduced object code ¡  Better error message ¡  Control over scope —  Enum ¡  Can be used instead of const ¡  Cannot take address of enum —  const_iterator
  6. 6. const 2/2 —  const return type —  const input parameter —  const member function of a class —  const overloading of member functions —  Use of mutable
  7. 7. casts —  static_cast —  dynamic_cast —  const_cast —  reinterpret_cast
  8. 8. Member initialization list —  Efficiency ¡  Default constructor plus assignment are replaced by copy constructor —  Order of declaration in class ¡  Order of initialization list —  Const and reference member ¡  must be initialized in member initializer list
  9. 9. inlining —  inlining does in-place replacement of code —  Improves efficiency —  Can lead to increased or decreased code size —  Inlining is a request to compiler —  Certain functions may not be inlined ¡  Called through function pointers ¡  Containing loops ¡  Virtual functions ¡  Constructor and destructor are worst candidates for inlining
  10. 10. Compilation —  forward declare where possible —  Keep declaration and definition in separate files ¡  Not possible for templates
  11. 11. Non-local static object initialization —  The order of initialization in different translation units is undefined ¡  Solution-> use function which return static object by reference
  12. 12. Default functions 1/2 —  Default functions ¡  default constructor, ¡  Assignment ¡  copy constructor ¡  destructor ¡  & operator —  If parameterized constructor is user defined, default constructor will not be provided —  default copy constructor does bitwise copy —  copy constructor and assignment operator not generated if, there is a ref member or const member
  13. 13. Default functions 2/2 —  To avoid default copy constructor ¡  declare them private and don't define them ¡  Derive from base class with private copy constructor ¡  Use boost::noncopyable
  14. 14. constructor destructor —  Virtual destructor ¡  Needed for base classes ¡  Compiler will invoke the base destructor only without it —  Pure virtual destructor ¡  To create abstract classes ¡  Having body in pure virtual destructor will help compiler while invoking the base class destructor —  Throwing exception ¡  Destructor should never throw exception
  15. 15. Inheritance 1/4 —  Design ¡  public inheritance ÷  Should always represent is-a relationship ¢  Penguin is not a bird ¢  Square is not a rectangle
  16. 16. Inheritance 2/4 —  Design ¡  Inheritance of interface v/s inheritance of implementation. ¡  public inheritance = inheritance of interfaces ¡  Pure virtual functions = inheritance of interface ¡  impure virtual functions = inheritance of interface plus inheritance of a default implementation. ¡  Non-virtual functions = inheritance of interface plus inheritance of a mandatory implementation.
  17. 17. Inheritance 3/4 —  Private inheritance (is implemented in terms of ) ¡  When only implementation is required ¡  e.g. class adapter pattern —  Names in derived classes hide names in base classes —  To make them visible ¡  Using declaration ¡  Forwarding function —  don't redefine non-virtual inherited function
  18. 18. Inheritance 4/4 —  Multiple inheritance complexities ¡  lead to ambiguity issues ¡  May need virtual inheritance. ¡  Virtual inheritance costs ÷  size, speed, and complexity of initialization and assignment. ¡  It's practical when base classes have no data. ¡  Some practical uses ÷  public inheritance for an Interface and private inheritance for implementation
  19. 19. Composition —  has-a relationship ¡  e.g. car has wheels ¡  Aggregation v/s composition ÷  In C++ a class having pointer members is composition whereas class having concrete members is aggregation ÷  Aggregation has full control of aggregated object ÷  Composition can share the contained object with other classes
  20. 20. Virtual Function —  Don’t call virtual function from constructor or destructor ¡  Derived part is not yet constructed when in base class constructor —  Never redefine an inherited default parameter value ¡  default parameter values are statically bound, ¡  virtual functions are dynamically bound.
  21. 21. Operator overloading —  Assignment operator should return reference to *this ¡  To support a = b = c ( chaining ) —  Check for self-copy in assignment operator ¡  If copying is deleting the existing object first, the object may delete itself
  22. 22. Copy constructor —  copy constructor should call base copy constructor
  23. 23. RAII —  Use constructor and destructor for resource management —  Use std::shared_ptr or std::scoped_ptr instead of raw pointers —  Use std::vector instead of arrays —  std::shared_ptr, with function object as argument for action other than delete
  24. 24. Misc —  new[] delete[] should be matched —  Namespace usage ¡  package extensibility ¡  better encapsulation ¡  precise control over what to include
  25. 25. Designing Interfaces —  Simple to use correctly and hard to misuse ¡  Consistency with built-in types ÷  a = b = c ¡  Restriction on types ¡  Constraining object values ÷  Date, Calendar ¡  Eliminating client side resource management

×