Effective c++notes
•
2 likes•1,666 views
The document summarizes key principles from Scott Meyers' book "Effective C++". It discusses best practices for variable declarations, passing parameters, using const, casts, member initialization lists, inlining functions, inheritance, composition, virtual functions, operator overloading, copy constructors, RAII, and designing interfaces. The overall focus is on writing efficient and well-structured C++ code.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Effective c++notes
Similar to Effective c++notes (20)
Recently uploaded
Recently uploaded (20)
Effective c++notes
- 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. —— 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. 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. 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. 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. const 2/2 — const return type — const input parameter — const member function of a class — const overloading of member functions — Use of mutable
- 7. casts — static_cast — dynamic_cast — const_cast — reinterpret_cast
- 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. 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. Compilation — forward declare where possible — Keep declaration and definition in separate files ¡ Not possible for templates
- 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. 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. 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. 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. Inheritance 1/4 — Design ¡ public inheritance ÷ Should always represent is-a relationship ¢ Penguin is not a bird ¢ Square is not a rectangle
- 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. 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. 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. 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. 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. 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. Copy constructor — copy constructor should call base copy constructor
- 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. Misc — new[] delete[] should be matched — Namespace usage ¡ package extensibility ¡ better encapsulation ¡ precise control over what to include
- 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