8
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

C++ Memory Models and Idioms

  • 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

Page 1: C++ Memory Models and Idioms

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

Page 2: C++ Memory Models and Idioms

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

Page 3: C++ Memory Models and Idioms

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

Page 4: C++ Memory Models and Idioms

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

Page 5: C++ Memory Models and Idioms

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 (...) { } }

Page 6: C++ Memory Models and Idioms

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

Page 7: C++ Memory Models and Idioms

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

Page 8: C++ Memory Models and Idioms

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.