effective_c++_notebook

Effective C++ NoteBook

Introduction

• std::size_t is just a typedef for some unsigned type in C++, such as count things
• Each functions declaration reveals its signature, included its return type

• Unless having a reason for implicit conversion, use explicit to declare a constructor

• Wdiget w1;
  Widget w2(w1); //copy constructor
  w1 = w2; //assignment constructor
  Wdiget w3 = w1; //copy constructor

• Pass-by-value

• bool function(Wdiget w);
  Widget a;
  if(function(a)){ //the object a is copied to the Widget w
  //call the copy constructor of Widget
  }

• Is a BAD CHOICE to pass the object by value, use the const reference

Accustoming Yourself to C++

• #define , will never get entered to symbol table
• repalce the define with ‘const variableName = constant’;
• the constant delared by const will only have one copy, not like to #define
• non-const static data member must be initialized out of line
• class Widget{
  static const int num1 = 5; //valid
  static int num2 = 5; //invalid
  static int num3; //valid
  }
  Widget::num3 = 10; //valid
• enum helps you get the constant during complilation
• For simple constants, prefer const objects or enums to #defines
• For funcion-like macros, prefer inline funcions to #defines
• const char* p = str; //non-const ptr, const data
  char* const p = str; //non-const data, const ptr
• the ptr passed to the function is just a copy, you can’t assigned what the ptr points to in a function, cuz what you changed was a copy
• const vector::iterator iter = vec.begin(); // like a T* const
  ++iter; //invalid
  vector::const_iterator iter = vec.begin(); // like a const T*
  *iter = 10; //invalid
• constant return val: help the compiler find the inapporpirate assignment, P19
• const member functions: which member functions may be invoked on const objects
• A better way to write the ABEntry constructor is to use the member ini- tialization list instead of assignments - more efficient approach
• the order of initialization of non-local static objects defined in different translation units.
• destructor should never throw exceptions
• Never call virtual functions during constrution or destruction: cuz base class constructor is called before the derived class constructor, and may call the pure virtual functions in base class, which is not hope to be seen
• Not only do virtual functions resolve to the base class, but the parts of the language using runtime type information (e.g., dynamic_cast (see Item 27) and typeid) treat the object as a base class type.
• Have assignment operators return a reference to *this.
• Happily, making operator= exception-safe typically renders it self- assignment-safe, too.

• class Widget { …
  void swap(Widget& rhs); // exchange *this’s and rhs’s data;
  … // see Item 29 for details
  };
  Widget& Widget::operator=(const Widget& rhs) {
  Widget temp(rhs); // make a copy of rhs’s data
  swap(temp); // swap *this’s data with the copy’s
  return *this;
  }

• A constructor initializes new objects, but an assignment operator applies only to objects that have already been initialized

Resource Management

• Use objects to manage resources
• factory function: return a ptr point to a dynamically allocated object
• Resource-managing objects use their destructors to ensure that resources are released.
• it’s important that there never be more than one auto_ptr pointing to an object.
• std::auto_ptr pInv1(createInvestment());
  std::auto_ptr pInv2(pInv1); //pInv1 get to NULL
  pInv1 = pInv2; //pInv2 get to NULL
• auto_ptr can only manage the resouces for dynamically allocated object, don’t adjust that to other cases
• don’t use more than single auto_ptr to the same resource
• using auto_ptr or tr1::shared_ptr with dynamically allocated arrays is a bad idea,
• std::auto_ptr p(new int(42)); //OK
  std::atuo_ptrp = new int(42);//Error
• string *str = new string(“abcd”);
  shared_ptr strptr(str);
  shared_ptr strptr2(str); //will crash !!!
• Store newed objects in smart pointers in standalone statements. Failure to do this can lead to subtle resource leaks when exceptions are thrown.

Designs and Declarations

• class Date {
  public:
  Date(const Month& m, const Day& d, const Year& y); // good design
  };

• class Month {
  public:
  static Month Jan() { return Month(1); } // return static !
  static Month Feb() { return Month(2); } // enum version is not type-safe
  static Month Dec() { return Month(12); }
  …
  private:
  explicit Month(int m);
  …
  };
  Date d(Month::Mar(), Day(30), Year(1995));

• tr1::shared_ptr supports custom deleters. This prevents the cross- DLL problem, can be used to automatically unlock mutexes (see Item 14), etc.
• What does it mean for objects of your new type to be passed by value? Remember, the copy constructor defines how pass-by- value is implemented for a type.
• function parameters are initialized with copies of the actual arguments, and function callers get back a copy of the value returned by the function.
• Passing parameters by reference also avoids the slicing problem : cutting what the derived class have and operate on a base class, it’s a bad idea
• Friends have the same access to a class’s private members that member functions have, hence the same impact on encapsulation
• // header “webbrowser.h” — header for class WebBrowser itself
  // as well as “core” WebBrowser-related
  namespace WebBrowserStuff {
  class WebBrowser { … }; …
  }
  // header “webbrowserbookmarks.h”
  namespace WebBrowserStuff {
  … }
  // header “webbrowsercookies.h”
  namespace WebBrowserStuff {
  }
• namespace could accross the file, while class couldn’t. Note that this is exactly how the standard C++ library is organized.
• It turns out that parameters are eligible for implicit type conversion only if they are listed in the parameter list.
• Declar a friend function to fit the promblem on 2 * object(can’t be compiled)
• the default swap function could change the whole data which the ptr points to, which is not efficient

Implementation

• Overuse of casts can lead to code that’s slow, hard to maintain, and infected with subtle bugs.
• const_cast is typically used to cast away the constness of objects. It is the only C++-style cast that can do this.
• dynamic_cast is primarily used to perform “safe downcasting,” i.e., to determine whether an object is of a particular type in an inher- itance hierarchy. It is the only cast that cannot be performed us- ing the old-style syntax. It is also the only cast that may have a significant runtime cost. (I’ll provide details on this a bit later.)
• reinterpret_cast is intended for low-level casts that yield implemen- tation-dependent (i.e., unportable) results, e.g., casting a pointer to an int. Such casts should be rare outside low-level code. I use it only once in this book, and that’s only when discussing how you might write a debugging allocator for raw memory (see Item 50).
• static_cast can be used to force implicit conversions (e.g., non-const object to const object (as in Item 3), int to double, etc.). It can also be used to perform the reverse of many such conversions (e.g., void* pointers to typed pointers, pointer-to-base to pointer-to-derived), though it cannot cast from const to non-const objects. (Only const_cast can do that.)
• doSomeWork(static_cast(15));//c++ style to cast an int to an object
• an offset is applied at runtime to the Derived* pointer to get the correct Base* pointer value.
• static_cast sometimes create a new object, for example, static_cast(*this) create a new object of current object
• Avoid returning “handles” to object internals. (handles == reference || pointer)
• const Point& upperLeft() const { return pData->ulhc; }
  const Point& lowerRight() const { return pData->lrhc; }//the left const disable the writing to the data, the right const disable the writing inside this funciton
• Functions offering the strong guarantee promise that if an excep- tion is thrown, the state of the program is unchanged.
• *