80 likes | 233 Views
C++ Memory Models and Idioms. Static member variables: a few more details Singleton design pattern Guard idiom and the auto_ptr class Copy on write idiom Reference counting idiom. More on Static Member Variables. If you don’t initialize a static member variable
E N D
C++ Memory Models and Idioms • Static member variables: a few more details • Singleton design pattern • Guard idiom and the auto_ptr class • Copy on write idiom • Reference counting idiom
More on Static Member Variables • If you don’t initialize a static member variable • Compiler initializes it for you, using 0 • This does not happen for non-static member variables • Initialization order guaranteed within compilation unit • Static member variables initialized before any function call • Good idea to define entire class in same compilation unit • No guarantees about order between compilation units • This can pose problems if a static is used in >1 source file • For example, if main accesses a static member directly
Singleton Design Pattern • Context • Applications that want to use shared globals (for good reasons) • For example, need to access flags/values set in a common GUI dialog • Problem • How to give safe access to a single global static instance • Design forces • Want to avoid constructing an instance until it’s used • Want to ensure initialization across compilation units • Solution outline • Make constructors private • Have a static member pointer to an instance of that class • Initialized to zero by the compiler • Have a static member function that returns that pointer • Defined in same compilation unit where pointer is initialized • Checks if it’s zero and if so creates/remembers one instance • Consequences • Can access from anywhere in the program via static member function • Avoids namespace collisions, accidental side effects
Guard Idiom • Context • Resources must be acquired or released in particular scopes • Problem • How to ensure allocated resources are always released • Design forces • Can exit scopes in many ways (code paths, exceptions) • Ensuring release via code paths increases complexity • May have dynamically allocated resources • Solution outline • Associate dynamic resources with a local “guard” variable • Guard’s constructor or other member fxn binds to resource • Guard’s destructor destroys a bound resource • Avoid double destruction by letting guard release resource
Guard idiom example C++ has an auto_ptr class template #include <memory> using namespace std; auto_ptr<X> assumes ownership of an X* auto_ptr destructor calls delete on the owned pointer Call release to break ownership by auto_ptr when it’s safe to do so Combines well with other memory idioms Foo *createAndInit() { Foo *f = new Foo; auto_ptr<Foo> p(f); init(f);// may throw exception p.release(); return f; } int run () { try { Foo *d = createAndInit(); } catch (...) { } } C++ auto_ptr Class Template
Copy on Write Idiom • Context • Many references to an object that is infrequently changed • Problem • How to make changes both efficient and transparent • Design forces • Changes should only be visible to user making the change • Copying should only occur when necessary (it’s expensive) • Solution outline • Add an ownership flag indicating who must delete a buffer • If you own a buffer you must destroy it before letting go of it • Make a copy when you want to change what’s referenced • Take ownership of any new copy you make • Otherwise, leave ownership responsibilities to others
Reference Counting Idiom • Context • A target object that is aliased from many locations • Problem • How to know when it’s safe to delete a referenced object • Design forces • Group of objects aliasing target object may change over time • Don’t destroy target object while other references to it exist • Destroy target object before last reference to it goes away • Solution outline • Store a counter with the target object being aliased • New alias to target object should increase the count • Decrease the count when stop aliasing target object • If count decreases to 0, destroy the target object
For Next Time • Review Session Thursday, October 20 • We’ll look at selected slides and ideas in class • Sample test questions will be posted on web • Midterm Exam Tuesday, October 25 • In the lecture hall, Whitaker 218 • 80 minutes, starting promptly at 10:10am • One 8.5” x 11” page allowed (both sides ok) • Exam is otherwise closed • no books, other notes, PDAs, cell phones, etc.