[Boost-users] shared_ptr, pimpl, reference semantics, and const correctness

31 Jul 2007

      I am continuing work on a futures library for boost.  future objects (as
currently considered by the C++ standards committee, in particular Peter
Dimov's proposal) have reference semantics, like many pimpl types.

I have some burning questions about const correctness.

Hypothetical reference-semantic example:

future f1;
future f2 = f1; //f2 refers to the same underlying object as f1
f2.set(42); //do something
assert(f1.get() == 42); // see, same underlying object

This is roughly equivalent to:
boost::shared_ptr<future_impl> f1;
boost::shared_ptr<future_impl> f2 = f1;

A std::vector<T>::iterator is an example of another type with reference
semantics.

So, say I have a simple future class:

class future_impl {
  public:
    bool get() const {return value_;}
    void set(bool value) {value_ = value;}
  private:
    bool value_;
};

class future { //not really a future, just example
  public:
    future() : impl_(new future_impl) {}
    future(const future &other) : impl_(other.impl_) {}
    bool get() const {return impl_->get();}
    // Set may not be const, but it does NOT really modify this class
    void set(bool value) {impl_->set(value);}
  private:
    boost::shared_ptr<future_impl> impl_;
};

I have made the future::set() method non-const, but it does NOT really modify
the underlying future class, only the future_impl class it refers to.

This makes life very difficult when it comes to passing futures by reference:

// alternative #1 - pass const future &
void f1(const future &f) {
  bool v = f.get(); // no problem, get() is const
  f.set(!v); // cannot do this, set() is not const

  // BUT I can bypass the const-ness trivially, so it is pointless
  future f2(f);
  f2.set(!v);
}

// alternative #2 - pass future &
// with #2, I can't do simple things like this:
// f2(future(f)); //ERROR: non-const reference from a temporary - irritating
void f2(future &f) {
  bool v = f.get(); // no problem, get() is const
  f.set(!v); 
}

// alternative #3 - pass by value
// Constructing shared_ptr's is VERY inefficient
void f3(future f) {
  bool v = f.get(); // no problem, get() is const
  f.set(!v); // cannot do this, set() is not const
}

// alternative #4 - const_future base class with the subset of const methods? 
// kinda like a const_iterator?  seems klunky.
class const_future {bool get() const;};
class future : public const_future {void set(bool);}

Does anyone have any advice or ideas?

Oh, and then there is a possible need for something like a
weak_ptr<future_impl>, like a weak_future class?  And then a const_weak_future?
I don't want to think about it...

Thanks,
Braddock Gaskill