Re: [boost] Why are we looking for a boost/Loki smart-pointer merginf?

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-20 15:51:36

From: "AlisdairM" <AlisdairM_at_[hidden]>
> 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.

This is a tough call. On one hand. you'd like to benefit of simplicity (so
that they can actually understand the source code by looking at the source
code :o)), good error messages, small include file overhead.

On the other hand however, as the need of functionality increases, the risk
of source code bloating increases as well. For example, all smart pointers
share a lot of skeleton code, which as of now is duplicated. Because of that
approach, you will have to start from scratch and design your own pointer
whenever you need any behavioral tweak (proprietary reference counting,
specific checking etc.). So at a point a unified approach becomes more
attractive because it gives you not only a number of objects, but also a
framework in which you can define your own.

Loki' SmartPtr class code itself has under 200 lines. It is admittedly
non-trivial code, but I don't think size puts it in the prohibitive area.
(By the way, I was thinking of separating various policies in various
include files.)

So there's a tension between the two tendencies.

> 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 ;? )

It's not really magic, and I was very glad to see that some found
Loki::SmartPtr to have a limited, imperfect design, and came up with ways of
improving it. It's in the nature of things. I also was happy to see a review
of mc+d on fatbrain saying that "Although this book was supposed to be
written for advanced readers, it's only good for beginners. [...] The design
solutions are not new and their implementation is not somewhat original.
Some solutions are interesting but not quite practical. Through out the book
the author tends to explain simplest things."

If nobody cares about it, magic stays magic. If really useful, yesterday's
magic is tomorrow's old hat. That's because the technique spreads, people
know about it, and it becomes common practice. I'd be plain scared if mc++d
would stay "cutting edge" five years from now :o).

> 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?

I'm planning to introduce similar array functionality in one of the policies
but the whole point is that that functionality, and many others, can be
easily introduced by the user without touching the Loki library itself.

On the other hand, I understand your concern, and I have no formed opinion
on the best route to follow.

Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/