Boost logo

Boost :

From: AlisdairM (AlisdairM_at_[hidden])
Date: 2002-01-20 03:46:00


As someone who is currently more of boost user than developer (although I
have been lurking here a while) and a happy user of Loki as well, I thought
it worth posing the question from a user perspective.

The Loki smart-pointer is a great piece of engineering, and a prime example
of policy-based design in C++. It is also a very complex piece of code.

boost::scoped_ptr has an incredibly simple job to do, and is fairly easy to
write. The simplicity of design is a large part of the appeal.

Trying to replace scoped_ptr with a typedef of the equivalent Loki is a big
step backwards for me, as that simplicity is a key part of the design.
Likewise, boost::shared_ptr is somewhat more complex, but tending to the
simplest possible design for a reference counted pointer suitable for use in
the standard containers. One very important thing these classes do is
provide an easy point of entry into boost libraries in general.

Loki smart pointer covers all those cases where you want to do something
more specific with your pointer. Such use may evolve when you discover the
scoped/shared pointer doesn't function EXACTLY as you need. When the
difference in behaviour becomes significant enough to worry about fixing,
then you are probably prepared to go the extra mile and work out how Loki
does its magic ;? )

While such typedefs would be instructive examples into working out what your
own pointer typedef should look like, I would hate to see the development of
these two libraries become too strongly tied together. Does it matter if
they don't have identical interfaces?

For instance, scoped_ptr has its sibling, scoped_array. Loki does not do
this, and neither does auto_prt. Rather than turn this into a submission
breaking issue, why not simply accept that Loki pointers are different?

The only time I see it as an issue is when both classes offer different
interfaces to the same functionality (a .get() function should always be
called .get(), principle of least surprise)

</returning to lurk mode>

AlisdairM


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk