Lecture Notes for Advanced Programming II

29 April 2004 - Handles Revisited

Outline

Reference counting handles.
Exceptions and exception safety.
Reference-counting Handles and exception safety.
Handle-reference handles and exception safety.
Mutable vs. const casting.

Handles

A handle is a form of smart pointer.
- It manages dynamic storage automatically.
A handle wraps POD pointers in a class.
- The constructors and destructor manage pointer data.
Writing a general purpose handle (or smart-pointer) class is hard.
- It's taken many smart people many years, and they still haven't got it right.

Handle Semantics

Handle copying can be implemented with copying or sharing.
Copying is inefficient but safe; sharing is efficient but unsafe.

Reference Counting

Shared storage management requires reference counting.
The reference count is also shared among all referring handles.
The alternative is to store the reference count in each handle.
- Which requires O(n) time to change.
- And requires knowing the other handles.

Unsharing for Safety

Sometimes sharing semantics can be a pain.

handle<widget> wh1(blue)
handle<widget> wh2(wh1)

wh2->color = red
// Now wh1->color is red too.

Unsharing makes a unique copy for a handle.

The unshare() member function copies storage.

template < typename T >
void handle::unshare()
  if (*ref_cnt > 1)
    (*ref_cnt)--
    ref_cnt = new size_t(1)
    t_ptr = t_ptr->clone()

Unsharing assumes the clone() operation.

Exceptions

Exceptions are an out-of-band communication channel.
- Different from globals, parameters, or return values.
Exceptions are a disruptive control and communication path.
- Procedures must handle an exception
  
  or be unwound.

Exceptions can come at any time and from any call.

Exception Safety

Exceptions should leave the program in a consistent state.
Weak exception safety prevents leaks and maintains a valid state.
Strong exception safety leaves the program state unchanged.
- This is an atomic property: the system's changed correctly or not changed at all.
Providing exception safety can be tricky.
- Smart pointers (handles, auto-pointers) can help, but not enough.

`unshare()` and Exception Safety

Is unshare() exception safe?
```
  if (*ref_cnt > 1)
1   (*ref_cnt)--
2   ref_cnt = new size_t(1)
3   t_ptr = t_ptr->clone()
```
1. After (*ref_cnt)--.
2. After ref_cnt = new size_t(1).
3. t_ptr->clone() throws an exception.

Making `unshare()` Exception Safe

Don't change shared state until it's safe.

if (*ref_cnt > 1)
  t_ptr = t_ptr->clone()
  (*ref_cnt)--
  ref_cnt = new size_t(1)

Is unshare() exception safe?
- Suppose new size_t(1) throws an exception.

Don't change handle state until everything's safe.

if (*ref_cnt > 1)
  T * tp = t_ptr->clone()
  size_t * rcp = new size_t(1)
  (*ref_cnt)--
  ref_cnt = rcp
  t_ptr = tp

Making `unshare()` Really Exception Safe

Is unshare() exception safe yet?

if (*ref_cnt > 1)
  T * tp = t_ptr->clone()
  size_t * rcp = new size_t(1)
  (*ref_cnt)--
  ref_cnt = rcp
  t_ptr = tp

What happens if new size_t(1) throws an exception?

Finally.

if (*ref_cnt > 1)
  T * const tp = t_ptr->clone()
  size_t * rcp
  try { rcp = new size_t(1) }
  catch (...) { delete tp ; throw }
  (*ref_cnt)--
  ref_cnt = rcp
  t_ptr = tp

Are Handles Exception Safe?

With unshare() fixed, are handles exception safe?

Here's a hint.

template < typename T >
handle::handle(T * tp) 
  : ref_cnt(new size_t(1)), t_ptr(tp) 
  { }

Here's another.
```
handle<widget> wh(new widget)
```
If new size_t(1) throws, new widget is lost.

We can fix that.

widget * wp = new widget
handle<widget> wh
try { wh = handle<widget>(wp) }
catch (...) { delete wp ; throw }

How convenient. Can we do better?

Handles Without Reference Counting

The problem occurs when allocating the reference count.
- The reference count needs to be allocated (that is, shared).
Do we need the reference count?
- The important numbers are one and more than one.
- One means delete the storage; more than one means don't.
How can we indicate one or more than one handle?
- If a handle can point to another handle, it's more than one.
- If a handle can only point to itself, it's one.

Handles with Handle References

Have all handles pointing to the same storage form a ring.
- A ring allows insertions and deletions anywhere in the ring.
Have the ring be doubly linked.
- A doubly-linked ring allows constant-time insertion and deletions.

Revised Handles

template < typename T >
class handle

  public:

    handle() 
      : tptr(0), next(this), last(this) { }

    handle(T * tp) 
      : tptr(tp), next(this), last(this) { }

  private:

    T * tptr
    mutable handle * next, * last

Member functions not shown are unchanged from reference counting.

Handle Reference Operations

The public rule of three.

handle(const handle & h) { relink(h) }

handle & operator = (const handle & rhs)
  if (this != &rhs)
    unlink()
    relink(rhs)

  return *this

~handle()
  unlink()

The private helper routines.

void unlink()
  if next == last
    delete tptr
  else
    next->last = last
    last->next = next

void relink(handle & h)
  next = &h
  last = h.last
  h.last = last->next = this
  tptr = h.tptr

When is `const` not `const`?

Notice the signature on assignment.

handle & operator = (const handle & rhs)

Is the right-hand side really constant?
- Yes; the referenced storage (if any) is unchanged.
- No; the handle's pointers are changed.
This is an example of logical constness vs. actual constness.
- rhs is logically but not actually const.

Const casts can deal with this problem

handle & operator = (const handle & rhs)
  if this != &rhs
    // whatever
    const_cast<handle &>(rhs).last = this

The copy constructor has a similar problem.

`mutable` vs. `const`

Using const casts to provide logical constness is clumsy.
- Casting syntax is clumsy.
- Const casts raise red flags, making code hard to understand.
- Plus, the compiler can ignore const casts.
The mutable modifier was defined to avoid these problems.
- A mutable instance field is always changeable, even in a constant instance.
```
mutable handle * last, * next

handle & operator = (const handle & rhs)
  if this != &rhs
    // whatever
    rhs.last = this
```

Bibliography

C/C++ Users Journal

These notes were derived from this article.

Smart Pointers Reloaded (IV): Finale by Andrei Alexandrescu and David Held, C/C++ Users Journal, April, 2004.

Combines reference counting and circular pointers to minimize heap-access overhead.

This page last modified on 6 May 2004.