Hello Boost-Users
CAVEAT
The attached code "works" but has a major design flaw
regarding pointer conversion safety -- one which can
currently either be accepted (at your risk) or
rectified by limiting usage to one-hop inheritance.
In particular, statement [3] (see below) is processed
without complaint in unsafe mode -- when it should
ideally provoke a compile-time error.
Indeed, providing a general type-safe solution is not
without challenge (read: my knowledge of C++ has been
exhausted). If interested, member function
'Common::reVamp' would be a good place to start.
PROBLEM
I recently needed a 'shared_ptr' that could be globally
reset -- that is, any one of the owners of the
controlled resource could unilaterally replace that
resource for the benefit (perhaps) of everyone else.
This has been named "global_reset" in previous postings
-- but I have adopted the shorter word "revamp".
Moreover, it would be useful if this newly conceived
"assign_ptr" could mimic the behavior of 'shared_ptr',
whilst simultaneously providing the additional
functionality. In particular, implicit upcasting
should be maintained.
This lead me to quickly reject options like:
shared_ptr ptrPtrResource;
And instead try to implement something like:
assign_ptr<T> py(new Y());
My environment is single-threaded and issues like CPU
cycles and memory consumption are not significant. Of
more importance to me was coding at a high level -- in
part, because I imagined that any conforming solution
could subsequently be refactored to improve on
performance and safety.
SOLUTION STRATEGY
The proposed solution has parallels with the Observer
pattern and relies on 'shared_ptr' to do most of the
work. Notwithstanding the code is now considerably
more involved than I had originally envisaged.
The biggest challenge was getting a multi-step
inheritance chain to play ball with the semantics and
syntax. Consider, if you would:
class A; // base class
class B : public A;
class C : public B; // and perhaps more
assign_ptr<B> b(new C()); // C resource held by B pointer [1]
assign_ptr<A> a = b; // resource now also held by A pointer
a.revamp(new C()); // not so simple to implement [2]
The statement marked [2] looks reasonable. But it
offers my observer class a challenge -- namely the need
to have available the type information present during
statement [1] when re-assigning the replacement
resource to 'b' during the 'revamp' call. In addition,
the following statement should fail in some way --
ideally at compile-time:
a.revamp(new A()); // okay for 'a', nonsensical for 'b' [3]
The following member functions are offered, noting that
the first two are already part of 'shared_ptr:'
a.use_count() // number of owners in the pool
a.unique() // true if use_count() == 1
a.revamp_count() // number of revamps
a.original() // true if revamp_count() == 0
a.external_count() // number of owners outside the pool
a.exclusive() // true if external_count() == 0
PRIOR DISCUSSIONS
The problem itself is noted in the Boost documentation:
Boost Libraries
+ Smart Pointers
+ shared_ptr class template
+ Smart Pointer Programming Techniques
+ Obtaining a shared_ptr from a raw pointer
One significant thread on this topic can be found at:
subject = shared_ptr and global reset
date = Feb-2009
http://thread.gmane.org/gmane.comp.lib.boost.user/45032/focus=45034
CODE
A single *.cc file is attached. This code was
developed using:
boost : 1.39.0 (built from source)
compiler : GCC g++ 4.1.2 (2006)
kernel : Ubuntu 6.10 Linux 2.6.17-12-generic
hardware : 1.4GHz Intel Celeron M / 512MiB RAM
DESIGN SUMMARY
This section gives a brief outline of the design
thinking I used. Note too that the code is also
extensively documented.
The point-of-entry is class template 'assign_ptr'.
This holds its own controlled resource pointer, just
like 'shared_ptr', but in this case, as a 'shared_ptr'.
It also holds a 'shared_ptr' to a class 'Common' object
(aka "Subject" under the Observer pattern). Class
'Common' manages a list of its 'Client's (aka
"Observers") and, in doing so, defines the pool. The
derived class template 'ClientImp' duly retains the
type of its associated 'assign_ptr'.
The various 'assign_ptr' member functions pass requests
to the 'Common' object, which responds accordingly.
Most of these member functions were declared above.
Class 'Common', in turn, contains the management
functions 'attach' and 'detach' and the interventionist
function 'reVamp'.
The remainder of the 'assign_ptr' implementation is
aimed at providing a similar interface to 'shared_ptr'.
Finally, everything is placed in namespace 'xeona'.
LITERATURE
Alexandrescu (2001, ch7, pp157-195) devotes a chapter
to smart pointers and the underlying design trade-offs
-- however "revamping" is not considered:
Alexandrescu, Andrei. 2001. Modern C++ design :
generic programming and design patterns applied.
Addison-Wesley, Boston, USA. ISBN 0-201-70431-5.
The notion of "revamping" is never far away in Meyers
(1996 item29 pp183-213) reference counting example, but
neither is it directly mentioned.
Meyers, Scott. 1996. More effective C++ : 35 new
ways to improve your programs and design.
Addison-Wesley, Boston, USA. ISBN 0-201-63371-X.
Some ideas regarding the use of Boost.Any came from the
following book (which I found both instructional and
nicely written):
Karlsson, Bjoern. 2006. Beyond the C++ Standard
Library : an introduction to Boost.
Addison-Wesley, Upper Saddle River, New Jersey,
USA. ISBN 0-321-13354-4.
The following web article offered some insights on
solutions:
Becker, Thomas. 2007. On the tension between
object-oriented and generic programming in C++ :
and what type erasure can do about it. C++ Source.
[http://www.artima.com/cppsource/type_erasure1.html]
Finally, Dattatri (2002 pp487-496) provides an
implementation of counted pointers and discusses the
design issues in some depth.
Dattatri, Kayshav. 2002. C++ : effective-object
oriented software construction : concepts,
principles, industrial strategies and practices --
Second edition. Prentice Hall PTR, Upper Saddle
River, New Jersey, USA. ISBN 0-13-086769-1.
ABOUT THE AUTHOR
I am a PhD student writing a policy-oriented energy
system simulation at the Institute for Energy
Engineering (IET), Technical University of Berlin
(TU-Berlin), Germany. I have never coded
professionally, but consider myself reasonably
competent in terms of scientific programming.
---
I am happy to take comments, suggestions, and patches
and will post an update in due course.
Please note that I will be checking my email only
infrequently over the next four weeks or so.
best wishes to all
Robbie Morrison
---
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : morrison@iet.tu-berlin.de
Webmail (preferred) : robbie@actrix.co.nz
[from IMAP client]
