Saturday, August 4, 2007

c++ review in a blast (core) - two


//50. value operator
//51. overloading assignment operator, operator=
//52. compiler implicitly creates a copy assignment operator for a class if you do not define one
//53. it overrides that definition of that of the base class
//54. assignment operator code
//55. copy assignment operator as virtual
//56. compiler choses the type of the pointer
//57. compiler choses the type of the object the pointer is pointing to
//58. copy constructor
//59. A&, const A&, volatile A&, const volatile A&
//59. if you did not declare one, compiler implicitly declares one for you
//60. implicitly defined copy constructor - A::A(A&) or A::A(const A&)
//61. copy constructor copies an existing object to a non-existing object,
// which you are going to create. assignment operator can happen between existing objects
//62. copy constructor is creating new a new object.
// the assignment operator has to deal with the existing data in the object.
// for a simple class, the work done may be the same, but for more complex
// classes,especially with pointers to other objects, there is a need to do more.
// this is related to the deep and shallow copy issue, ownership, is-a-part relationship.
//63. c++ is more strongly typed than c. c allows void*
//64. reference is like a const pointer that is automatically dereferenced
//65. a reference must be initialized when it is created, pointers can be later
//66. once a reference is initialized to an object, it cannot be changed to refer
// to another object - pointers can be anytime
//67. you cannot have null references. you must always be able to assume that
// a reference is connected to a legitimate piece of storage.
//68. member scope
//69. find the fun - then just do it - when you feel enjoying it. side note :)
//70. i want a high energy, adrenaline-rush environment - just extracts the best in one
//71. keep it light and simple, and be kind - no rules, all learn together
//72. const ref - function will not modify
//73. pointer references
//74. argument passing guideline
//75. ideal default habit - pass by const reference
//76. it isn't just about performance early, more at stake
//77. pass by value requires constructor and destructor calls
//78. if you are not going to modify the argument, passing by const reference only
// needs an address pushed on the stack
//79. pass by value only when you wanted to do something bizarre :) to an object
// and the caller is not expecting it, make your own copy then
//80. X(X&) / "X of X ref" - copy constructor
//81. do not aim for perfection, aim for liquidity
//82. this constructor is essential to control passing and returning of user-defined types
// by value during function calls.
//83. it's so important, in fact, that the compiler will automatically synthesize a
// copy constructor if you don't provide one yourself.
//84. understand the need for copy constructor
//85. delete - delete objects
//86. delete[] - delete array
//87. delete operator destroys the object created with new by deallocating the
// memory associated with the object
//88. dynamic memory allocation, deallocation
//89. pointer will be copied but memory it points to will not
//90. original object and copied object points to same object in memory, not one's intention
//91. default copy constructor and assignment operator are shallow copies
//92. to make a deep copy, you must write a copy constructor and overload operator=
//93. deep copy is needed if an object has pointers to dynamically allocated memory
// and that memory needs to be copied when the original object is copied
//94. the class generally needs destructor to delete the dynamically allocated memory,
// copy constructor and overloaded assignment operator
//95. copy constructor is a constructor - creates new object from garbage
//96. assignment operator - copies state of an existing object to another existing object
//97. if you don't want a class to be copied, make an empty cc and ao and make them
// private or protected
//98. compiler isn't guaranteed to create versions of these classes that do exactly
// what you want them to do
//99. assignment operator has to take into account the current state of the object
// when copying the other object's state into it
//100. the current state does matter, and assignment operator is more complicated
//101. you have to do your own memory management
//102. every 'new' that happens during program execution should be balanced
// by one and only one 'delete'
//103. you don't want objects you've created to clutter in memory after you're done with them
//104. you don't want to delete an object more than once, and
//105. you don't to access an object after you have deleted it
//106. double deleting will corrupt the memory manager free list, leading to crushes down
// the road
//107. protocol for managing memory
//108. example protocol: for every object in the runtime environment,
// there is only one and only one pointer to it through which the object can be deleted.
// this pointer is an "owning pointer", and the object or function containing that pointer
// is the object's "owner".
// all other pointers to the object are called "aliasing pointers."
// the owner of the object is expected to delete the object; objects with aliasing
// pointers don't
//109. dangling pointer - a pointer pointing to a deleted object in memory
//110. how about "transmitting of ownership" / return value is an owning pointer -
// passes ownership to the caller
//111. at other times, a function returns a pointer to an object but intends that the
// caller merely use it for a short time to perform some operation.
// ownership is not transferred; the return pointer is an "aliasing pointer"
//112. when you have functions that return pointers or have pointer parameters,
// you must make it explicit whether the function transfer ownership, and
// you must then make sure that code calling the function upholds this semantics.
// c++ doesn't do any of these for you
//113. sometimes you can do this through parameter types (references are virtually
// always aliases, and const pointers are always aliases)
//114. sometime you have to do it through naming conventions - e.g. "adopt"/"orphan"/"create"
// in the names of the functions that transfer ownership
//115. an assignment operator's const reference parameter signifies that we are not
// taking ownership of its internal state (there are some very rare exceptions to this)
//116. as an aside, its worth mentioning that there are occasions where copying objects
// to maintain ownership semantics is too expensive. in this situation, a technique called
// 'reference counting' can be used