[boost] Re: Yet Another Pointer Policy Proposal... Fast One

From: David B. Held (dheld_at_[hidden])
Date: 2002-07-28 14:57:49

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:ahu5l6$ign$1_at_main.gmane.org...
> [...]
> Agreed, but the 'why' implies 'perfection'.  At the same time, it's kind
> of hard to propose new classes related to pointers since everything
> is based on those.

No, the debate isn't about whether your class is perfectly implemented
or not.  The debate is on how much overlap exists between your proposal
and existing smart pointers.  That, and the cost of your usage syntax vs.
the benefits it brings.  It seems that your syntax is hard to remember and
could be easily abused.  I certainly wouldn't know how to use your pointer
without studying it for a while, whereas, using the existing
boost::smart_ptr
is as simple as using std::auto_ptr, for the most part.

> [...]
> Well, a lot of programming languages includes different reference
> count techniques and garbage collectors like Sather, Java, ...  it is
> hard to diverge the subject when C++ is supposed to be the most
> efficient language (illogical in a way).

I don't know that C++ is supposed to be the most efficient language.  It
has benefits and disadvantages, and hopefully, you choose it because it
is the most appropriate tool for the job at hand.  There are surely times
when Java or another language is more appropriate.  And while
efficiency is definitely a concern for the design of C++ programs and C++
itself, most people are more worried about correctness, which is much
harder to get right than raw speed.  Part of correctness includes
portability.  After all, very few compilers are fully standard compliant, so
just because something compiles on gcc doesn't mean it will compile
on anything else.  But I think you learned that already. ;)

> Who is taking decisions to validate boostlib official changes?

Changing existing Boost libraries is under the jurisdiction of the library
author(s)/maintainer(s).  Accepting a new library involves a formal review
process.  If you want Boost to consider your pointer, ask the Review
Wizard for a formal review.

> I would like simply to know if other people agrees with my class
> (xmm) so that I won't be the only one using it and that I could put
> serious efforts to integrate the class.

So far, it seems that not many other people have the performance
needs that you do, which is why they might be reluctant to examine
your code.  That, and the fact that smart pointers exist that do most
of what they want already present a particular challenge to your
proposed library.

> [...]
> Sorry, it was for pointer-based policies and is usefull for different
> allocation technique; flexible enough.

Your squad_ptr<> is *not* "policy-based".  A policy-based design,
simply put, is one in which some of the template parameters define
the behaviour of the class.  In your case, the class' behaviour is
independent of the single template parameter (or at least, it should
be!).  If you take a closer look at one of the policy-based designs in
the vault, you can perhaps see what is meant by a "policy-based
design".  But my description is surely not adequate.  Look up one of
the many references to get a better idea.

> [...]
> I will change statement declarations to:
> shared_ptr< rc<parent> > p = new (new (xmm) child("John", "McInnis"))
> rc<child>;
> [...]

This is abominable.  I would never try to use a pointer like this.  I
would probably prefer raw pointers, which have even more speed,
and are considerably easier to use.

Dave