ECE 449 OOP and Computer Simulation Lecture 12 Resource Management II

Size: px

Start display at page:

Download "ECE 449 OOP and Computer Simulation Lecture 12 Resource Management II"

Merilyn Walsh
5 years ago
Views:

1 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 1/62 ECE 449 OOP and Computer Simulation Lecture 12 Resource Management II Professor Jia Wang Department of Electrical and Computer Engineering Illinois Institute of Technology November 10, 2017

2 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 2/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

3 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 3/62 Reading Assignment This lecture: 14 Next lecture: None

4 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 4/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

5 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 5/62 Worry-Free Memory Management For our simulator, we know exactly when the objects created on the heap should be deleted. The deletes are centralized in dtors. For other applications, it is possible one cannot decide the exact place where objects should be deleted. It is now programmers responsibility to delete them correctly. That s impossible for the majority of the programmers garbage collection (GC) is a must Programmers decide when objects should be created on the heap. The compiler/runtime library decide when they should be deleted. Typical garbage collection algorithms Reachability analysis: reclaim memory when necessary Reference counting: delete an object immediately when it s no longer in use

6 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 6/62 Smart Pointers Smart pointers: class types that can be used as pointers but are smarter than built-in pointers. They will delete an object when it is no longer in use. Provide GC to C++ programs std::unique_ptr: keep a non-copyable pointer to an object It is straight-forward to determine when the object should be deleted in its dtor. std::shared_ptr: allow to share a pointer to an object Reference counting is used to determine when the object should be deleted.

7 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 7/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

8 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 8/62 Reference Counting For each object created on the heap, we need to maintain a number indicating how many pointers points to it. The number is called the reference count, or the count. The object should be deleted when the count becomes 0. Where should we store the count? The count should be per object, and have the same lifetime as the object. We may ask each object to hold a count, but that s not a good solution. Solution: create the count on the heap and delete it when the object is deleted How should we update the count correctly? Manually when the pointer is copied/discarded? Too tedious and error prone Solution: wrap the pointer in a class so the count can be updated automatically

9 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 9/62 The shared ptr Class template<class T> class shared_ptr { T *p_; int *count_; ; // class shared_ptr<t> Let s define shared_ptr as a class template so it can be used for any type of pointers. count_ will maintain a pointer to the reference count, created on the heap.

10 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 10/62 Class Invariants template<class T> class shared_ptr { T *p_; int *count_; ; // class shared_ptr<t> Either both p_ and count_ are NULL, Or there are *count_ number of shared_ptr<t> objects holding the pointers pointing to *p_. Other pointers pointing to *p_ are not counted since one should access the object only through shared_ptr<t>.

11 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 11/62 Default Ctor template<class T> class shared_ptr { T *p_; int *count_; public: shared_ptr() : p_(null), count_(null) { ; // class shared_ptr<t> For default ctor, we can simply set the pointers to NULL.

12 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 12/62 Dtor template<class T> class shared_ptr { T *p_; int *count_; public: ~shared_ptr() { if (count_!= NULL) { --*count_; if (*count_ == 0) { delete p_; delete count_; ; // class shared_ptr<t> We should decrease the count by 1 in dtor since there is one less shared_ptr<t> object holding the pointers. The object and the count should be deleted when the count drops to 0.

13 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 13/62 Ctor template<class T> class shared_ptr { T *p_; int *count_; public: shared_ptr(t *p) { try { count_ = new int(1); // initialize the count to 1 p_ = p; catch () { delete p; throw; ; // class shared_ptr<t> If we fail to create the count on the heap, we should also delete the pointer. The user of the class shared_ptr<t> should not be bothered by such issue as if the creation of the object is failed.

14 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 14/62 Implicit Construction void some_function(const shared_ptr<int> &p); void another_function() { int i = 0; some_function(&i); Since a ctor of shared_ptr<t> would take a pointer to T as the argument, the above code is valid as the construction is done implicitly. But it s wrong the object is not created on the heap. Although we cannot prohibit someone to construct a shared_ptr<t> object from a pointer to an object not created on the heap, we should highlight the creation of the shared_ptr<t> objects by prohibiting such implicit construction.

15 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 15/62 explicit Construction template<class T> class shared_ptr { T *p_; int *count_; public: explicit shared_ptr(t *p) { ; // class shared_ptr<t> The explicit keyword indicates the construction through the ctor must be explicit. Note that for ctors with at least two parameters w/o default arguments, construction must be explicit and it is not necessary to use explicit.

16 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 16/62 shared ptr and new void some_function(const shared_ptr<int> &p); void another_function() { int i = 0; // some_function(&i); // won t compile some_function(shared_ptr<int>(&i)); // wrong some_function(shared_ptr<int>(new int(5)); // correct Programmers can quickly identify errors with highlighted constructions. If a shared_ptr<t> object is constructed and there is no new, then something could be wrong. It is also possible to enforce every new to be accompanied by a shared_ptr<t> construction.

17 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 17/62 Copy Ctor template<class T> class shared_ptr { T *p_; int *count_; public: shared_ptr(const shared_ptr<t> &sp) : p_(sp.p_), count_(sp.count_) { ++*count_; ; // class shared_ptr<t> For a built-in pointer, making a copy means to copy the address of the object instead of to copy the object itself. Same rule applies here we make a copy of the pointer to the object, and a copy of the pointer to the count. That s why we call shared_ptr<t> smart pointer. Need to increase count by 1 Note that the parameter of the copy ctor should use the exact type shared_ptr<t> instead of shared_ptr.

18 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 18/62 Assignment template<class T> class shared_ptr { T *p_; int *count_; public: shared_ptr<t> &operator=(shared_ptr<t> rhs_copy) { swap(rhs_copy); return *this; ; // class shared_ptr<t> For exception safety, let s use copy-and-swap. Note that both the return type and the parameter should use the exact type shared_ptr<t>.

19 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 19/62 Swap template<class T> class shared_ptr { T *p_; int *count_; public: void swap(shared_ptr<t> &sp) { std::swap(p_, sp.p_); std::swap(count_, sp.count_); ; // class shared_ptr<t> It s straight-forward: just swap the members.

20 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 20/62 Pointer Operations void some_function() { shared_ptr<std::string> p(new std::string); *p = "string"; // operator* p->size(); // operator-> We need to overload * and -> such that a smart pointer can be used like a built-in pointer. Pointer arithmetics are not supported since it points to an object but not an array of object.

21 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 21/62 Dereference template<class T> class shared_ptr { T *p_; int *count_; public: T &operator*() const { assert(p_!= NULL); return *p_; ; // class shared_ptr<t> * should return a reference to the object on heap. * won t change the pointer and thus can be a const member function.

22 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 22/62 Arrow template<class T> class shared_ptr { T *p_; int *count_; public: T *operator->() const { assert(p_!= NULL); return p_; ; // class shared_ptr<t> C++ allows to overload -> but not.. Unlike other operators, when -> is overloaded, the compiler would interpret p->size() as p.operator->()->size(). -> should return a pointer to the object on heap.

23 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 23/62 Accessor template<class T> class shared_ptr { T *p_; int *count_; public: T *get() const { return p_; ; // class shared_ptr<t> In case the pointer is needed, users can access it through get(). It should be used with care. Note that one can always access the pointer by taking the address of the reference returned by * so get() doesn t expose more information of the smart pointer.

24 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 24/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

25 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 25/62 Activity I typedef shared_ptr<std::string> str_ptr; str_ptr create_string(std::string s) { return str_ptr(new std::string(s)); str_ptr some_function() { str_ptr sp_first = create_string("first"); str_ptr sp_second(new std::string("second")); str_ptr sp; sp = sp_first; sp_first = sp_second; return sp; What objects are created on the heap and when they are deleted?

26 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 26/62 Activity I: Step 1 str_ptr create_string(std::string s) { return str_ptr(new std::string(s)); str_ptr some_function() { str_ptr sp_first = create_string("first"); Assume copy ctor is not optimized away by the compiler. Let s use (str, count) to represent the object and its reference count on the heap. Inside create_string, a temporary str_ptr object is first created pointing to ("first", 1). It is then copied to the return value: the pair becomes ("first", 2). When the function returns, the temporary str_ptr object is destroyed: the pair becomes ("first", 1).

27 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 27/62 Activity I: Step 2 str_ptr some_function() { str_ptr sp_first = create_string("first"); str_ptr sp_second(new std::string("second")); str_ptr sp; The return value of create_string is copied to sp_first: the pair becomes ("first", 2). A new pair ("second", 1) is created and pointed by sp_second. sp holds NULL members.

28 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 28/62 Activity I: Step 3 str_ptr some_function() { str_ptr sp_first = create_string("first"); str_ptr sp_second(new std::string("second")); str_ptr sp; sp = sp_first; sp_first = sp_second; sp_first is assigned to sp: both of them point to the pair ("first", 3) The return value of create_string is not destroyed yet that s the third smart pointer pointing to the pair. sp_second is assigned to sp_first: both of them point to the pair ("second", 2) The reference count to "first" is decreased by 1 to 2. sp and the return value of create_string point to the pair ("first", 2).

29 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 29/62 Activity I: Step 4 str_ptr some_function() { str_ptr sp_first = create_string("first"); str_ptr sp_second(new std::string("second")); str_ptr sp; sp = sp_first; sp_first = sp_second; return sp; sp is copied to the return value of some_function: the pair they point to becomes ("first", 3). What happens when some_function returns? Local variables are destroyed in the reverse order of construction.

30 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 30/62 Activity I: Step 5 str_ptr some_function() { str_ptr sp_first = create_string("first"); str_ptr sp_second(new std::string("second")); str_ptr sp; return sp; Before some_function returns, ("first", 3): sp, return value of some_function, return value of create_string ("second", 2): sp_first, sp_second sp is destroyed: ("first", 2). sp_second is destroyed: ("second", 1) sp_first is destroyed: ("second", 0) The pair is then deleted from the heap. Return value of create_string is destroyed: ("first", 1) Finally, we only have the pair ("first", 1), which is pointed by the return value of some_function.

31 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 31/62 Activity II struct B; struct A { shared_ptr b_of_a; ; // struct A struct B { shared_ptr<a> a_of_b; ; // struct B void some_function() { shared_ptr<a> pa(new A); shared_ptr pb(new B); pa->b_of_a = pb; pb->a_of_b = pa; Any thing wrong?

32 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 32/62 Activity II: Cycles Lead to Memory Leakage struct B; struct A { shared_ptr b_of_a; ; // struct A struct B { shared_ptr<a> a_of_b; ; // struct B void some_function() { shared_ptr<a> pa(new A); // (A, 1) shared_ptr pb(new B); // (A, 1), (B, 1) pa->b_of_a = pb; // (A, 1), (B, 2) pb->a_of_b = pa; // (A, 2), (B, 2) // pb is destroyed: (A, 2), (B, 1) // pa is destroyed: (A, 1), (B, 1) Memory leakage! Limitation of reference counting based smart pointers: at runtime, if the smart pointers form a cycle, resources won t be released properly.

33 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 33/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

34 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 34/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

35 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 35/62 Pointers and Incomplete Types class A; // forward declaration bool operation_one(a *p); void operation_two(a *p); void combined_operation(a *p) { if (operation_one(p)) { operation_two(p); You can implement combined_operation without knowing anything about A. In this context, the type A is incomplete. Using incomplete types is a typical method to hide all implementation details. Especially for C where OO is not supported directly, e.g. FILE *

36 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 36/62 Smart Pointers and Incomplete Types class A; // forward declaration bool operation_one(shared_ptr<a> p); void operation_two(shared_ptr<a> p); void combined_operation(shared_ptr<a> p) { if (operation_one(p)) { operation_two(p); What if we replace A * with shared_ptr<a> as implemented in the last lecture? The code won t compile. When combined_operation returns, the dtor of shared_ptr<a> will be called. Since the dtor of shared_ptr<a> is a member of a class template, it is instantiated here. It need to access the dtor of A for delete, but that s not available since A is incomplete.

37 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 37/62 Pointers and Derived Types class derived : public base { ; // class derived bool base_operation(base *p); void some_function(derived *p) { if (base_operation(p)) { // do something here Implicit conversion works here to convert a derived pointer to a base pointer.

38 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 38/62 Smart Pointers and Derived Types I template<class T> class shared_ptr { T *p_; int *count_; public: template <class U> shared_ptr(const shared_ptr &sp) : p_(sp.p_), // ensure U is T or derived from T count_(sp.count_) { ++*count_; ; // class shared_ptr<t> We can enable the implicit conversion among smart pointers by introducing a template ctor to replace the copy ctor. Note that if U is not T or is not actually derived from T (except T is void), then p_(sp.p_) won t compile.

39 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 39/62 Smart Pointers and Derived Types II bool base_operation(shared_ptr<base> p); void some_function(shared_ptr<derived> p) { if (base_operation(p)) { // do something here In such case, there is a chance the derived object will be deleted through the base pointer. If the dtor of base is not virtual, memory leakage may happen. C++ does allow a base class to have a dtor not being virtual.

40 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 40/62 Pointers and Smart Pointers Our implementation of shared_ptr is not quite like built-in pointers Need a complete type when used Cannot handle derived objects with base pointers As the issues are both with the delete in dtor, can we modify the implementation to address them? In addition, can we use the same idea to manage resources not on heap? Store a pointer to a local object (with care) in shared_ptr Use shared_ptr to manage resources like FILE *

41 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 41/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

42 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 42/62 delete and Abstraction ~shared_ptr() { if (count_!= NULL) { --*count_; if (*count_ == 0) { delete p_; delete count_; // <=========== here is the problem All issues happen when we attempt to delete a pointer in the dtor of shared_ptr. We need to make sure we are deleting the pointer with the correct type. Or don t delete at all if the resource is not on heap We need an abstraction of deletion to hide how the resource should be deleted/released.

43 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 43/62 Abstraction by Runtime Polymorphism class ref_count { ref_count(const ref_count &) = delete; ref_count &operator=(const ref_count &) = delete; virtual void destroy() = 0; int count_; public: void inc_ref(); void dec_ref(); protected: ref_count() : count_(1) { virtual ~ref_count() { ; // class ref_count The abstraction could be defined through the pure virtual function destroy. Follow the template method pattern, the reference count is managed in the same class. The template methods are inc_ref and dec_ref.

44 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 44/62 Implement inc ref and dec ref class ref_count { void inc_ref() { ++count_; void dec_ref() { --count_; if (count_ == 0) { destroy(); delete this; ; // class ref_count The virtual dtor ensures derived objects of ref_count will be deleted correctly through ref_count pointers. These two functions can be further tweaked for multi-threaded programs/ multi-core platforms.

45 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 45/62 Updated shared ptr Class template<class T> class shared_ptr { T *p_; ref_count *count_; public: template <class U> shared_ptr(const shared_ptr &sp) : p_(sp.p_), count_(sp.count_) { count_->inc_ref(); ~shared_ptr() { if (count_!= NULL) count_->dec_ref(); ; // class shared_ptr<t> The data member for reference count, the template ctor, and the dtor should be updated. All other members except shared_ptr(t *p) remain the same.

46 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 46/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

47 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 47/62 Resources on Heap template <class T> class ref_count_heap : public ref_count { T *p_; virtual void destroy() { delete p_; public: ref_count_t(t *p) : p_(p) { ; // class ref_count_heap<t> For resources on heap, the ref_count_heap<t> class is designed. It should hold a pointer to the object of type T on heap. The destroy function implements how the object should be deleted. We do need more storage for a ref_count_heap<t> object than a simple int. There is always trade-offs in your design. Here we prefer usability since the storage overhead is acceptable.

48 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 48/62 Updated Ctor template<class T> class shared_ptr { T *p_; ref_count *count_; public: explicit shared_ptr(t *p) { try { count_ = new ref_count_heap<t>(p); p_ = p; catch () { delete p; throw; ; // class shared_ptr<t> Note that we use the base pointer count_ to store a derived object created by new on heap.

49 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 49/62 Construction with a Complete Type template<class T> class shared_ptr { explicit shared_ptr(t *p) { count_ = new ref_count_heap<t>(p); delete p; ; // class shared_ptr<t> shared_ptr<a> create_object() { return shared_ptr<a>(new A); shared_ptr(t *p) is instantiated when called. At that point, the type T (A) should be complete since we expect *p to be created on the heap in the same statement. delete p should compile without a problem. ref_count_heap<t> is instantiated at the line count_=

50 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 50/62 Instantiation of ref count heap<t> count_ = new ref_count_heap<t>(p); For a class template, the data members are instantiated when an object of the class is referred to; an member function is instantiated when they are referred to. For the above line, clearly it would lead to the instantiation of the data members and the ctor. The dtor and destroy will be referred within the ctor as they are virtual. So they are also instantiated here. As the type T (A) is complete here, destroy will compile correctly.

51 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 51/62 Handle Incomplete Types class A; // forward declaration bool operation_one(shared_ptr<a> p); void operation_two(shared_ptr<a> p); void combined_operation(shared_ptr<a> p) { if (operation_one(p)) { operation_two(p); The dtor of shared_ptr<a> may eventually call the virtual function destroy of ref_count to release the object. The compiler don t need to instantiate ref_count_heap<a>::destroy here and don t need to know the complete type of A here. Is count_ pointing to a ref_count_heap<a> object? No more compiling error!

52 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 52/62 Handle Derived Types template<class T> class shared_ptr { template <class U> shared_ptr(const shared_ptr &sp) : p_(sp.p_), count_(sp.count_) { count_->inc_ref(); ; // class shared_ptr<t> count_ will point to an object that knows the exact type of p_. We ll always release the object pointed by p_ through a pointer of its actual type. No memory leakage!

53 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 53/62 Assignment and Derived Types void some_function() { shared_ptr<derived> sp_derived(new derived); shared_ptr<base> sp_base; sp_base = sp_derived; // will it work? Do we need to implement a template operator= to support the assignment? shared_ptr<base>::operator= asks for an argument of type const shared_ptr<base> &. The compiler will use the template ctor to construct a shared_ptr<base> object from sp_derived. It compiles and works correctly with the current implementation.

54 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 54/62 What if shared_ptr<base> create_derived_object() { return shared_ptr<base>(new derived); The pointer to the derived object will be converted to a base pointer implicitly. Memory leakage may happen. I know you can implement the function as shared_ptr<base> create_derived_object() { return shared_ptr<derived>(new derived); But what if someone forgot to do so?

55 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 55/62 Another Template Ctor template<class T> class shared_ptr { template <class U> explicit shared_ptr(u *p) { try { count_ = new ref_count_heap(p); p_ = p; // ensure U is T or derived from T catch () { delete p; // another place that need the exact type of p throw; ; // class shared_ptr<t> By extending the ctor shared_ptr(t *p) to a template, we can obtain the exact argument type for construction. The type information is then used to create the correct ref_count_heap object on heap.

56 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 56/62 Outline Smart Pointers Reference Counting and shared ptr Activities Abstraction by Polymorphism Issues with Our Implementation Abstraction by Runtime Polymorphism Handle Incomplete Types and Derived Types Beyond Memory Management

57 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 57/62 Deleters template <class T, class D> class ref_count_deleter : public ref_count { T *p_; D deleter_; virtual void destroy() { deleter_(p_); public: ref_count_t(t *p, D d) : p_(p), deleter_(d) { ; // class ref_count_deleter<d> We can further generalize delete by a deleter. For now, let s say a deleter is a function that releases a kind of resources not created on heap. We can derive the class ref_count_deleter<t,d> from ref_count where D is the type of the deleter function. As we will see later, type argument deduction will be leveraged to generate the type D and we don t need to specify it explicitly.

58 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 58/62 Template Ctor and Deleters template<class T> class shared_ptr { template <class U, class D> shared_ptr(u *p, D d) { try { count_ = new ref_count_deleter<u, D>(p, d); p_ = p; catch () { d(p); // if fails, we release p using the deleter d throw; ; // class shared_ptr<t> Similar to template <class U> shared_ptr(u *p), we can obtain the exact argument types for construction with deleters by a template ctor. The types U and D are used to create the correct ref_count_deleter object on heap.

59 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 59/62 Example I: Local Objects void null_deleter(void *) { // do nothing void some_operation(shared_ptr<a> p); void some_function() { A a; shared_ptr<a> sp0(&a, null_deleter); some_operation(sp0); shared_ptr<a> sp1(new A); some_operation(sp1); sp1 = sp0; sp0 = shared_ptr<a>(new A); With a deleter that does nothing, we can store a pointer to a local object in shared_ptr. Be careful for its lifetime. It can be use together with the smart pointers with objects created on heap. The derived classes of ref_count will make sure all objects are deleted correctly.

60 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 60/62 Example II: Objects not on Heap void some_function() { shared_ptr<file> f(fopen("data.txt", "r"), fclose); file_operation(f); The file will be closed when it is no longer in use.

61 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 61/62 Example III: Clean-ups and Exception Safety void some_function() { shared_ptr<void> p(malloc(1000), free); if () { return; else if () { return; Clean-ups are done automatically. Also guarantee exception safety It is the easiest way to bridge your C++ code with libraries that provide a C interface.

62 ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 62/62 Summary and Advice std::shared_ptr provides reference counting based GC and resource management to C++ programs. It helps to improve the quality of application and should be used whenever you cannot determine the exact lifetime of an object. However, programmers should ensure no cycle may form at runtime to prevent resource leakage. Polymorphism is the key element in library design. Use runtime polymorphism to hide detailed type information so couplings are minimum Use compile-time polymorphism to extract detailed type information so cases can be handled in the correct way The two can be combined to achieve elegant solutions for many design problems.

ECE 449 OOP and Computer Simulation Lecture 14 Final Exam Review

ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 1/35 ECE 449 OOP and Computer Simulation Lecture 14 Final Exam Review Professor Jia Wang Department of Electrical