1 / 8

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. More on Static Member Variables. If you don’t initialize a static member variable

charo
Download Presentation

C++ Memory Models and Idioms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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.

More Related