From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-20 15:44:02
Rather than get bogged down in the details, let's focus on your big picture
Why are we looking for a boost/Loki smart-pointer merge?
The reasoning is that it is often (but not always) good software
engineering to combine components with a great deal of overlapping
functionality into a single more generic component. If a boostified
version of Loki::SmartPtr can provide 100% of the functionality of the
boost smart pointers, not provide unwanted functionality for the simpler
cases, plus cover a lot of cases not currently covered by boost smart
pointers, why not replace the boost smart pointers with the boostified
(We've been looking for such a replacement since before Loki::SmartPtr was
One possible objection is the user interface complexity of the policy
template parameters. There are several possible fixes for that - a policy
adapter or named template parameters, for example. Another fix is to
provide typedef templates (or forwarding classes, until typedef templates
are available) for the most common use scenarios.
At the moment we are still probing the design space. It may not work out.
Also note there is a lot of pressure on boost::shared_ptr to evolve. The
boost smart pointers are seen as the beginning, not the end. If they are
going to end up evolving into something functionally very like
Loki::SmartPtr, why not jump there directly?
But the jury is still out.
At 03:46 AM 1/20/2002, AlisdairM wrote:
>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
>it worth posing the question from a user perspective.
>The Loki smart-pointer is a great piece of engineering, and a prime
>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
>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
>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
>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
>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
>own pointer typedef should look like, I would hate to see the development
>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>
>Info: http://www.boost.org Send unsubscribe requests to:
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk