Upload
charo
View
23
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
C++ auto_ptr Class Template
• 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 (...) { } }
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
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
CSE 332: C++ memory models and idioms
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.