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

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-27 08:09:45

"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
news:ahtmq6$rt$1_at_main.gmane.org...
>
> "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> news:ahtikv$rcj$1_at_main.gmane.org...
> > Ok.  I've concluded that no one replies when it's not perfect.
>
> Hi, Philippe
>
> I would conclude the following: nobody what to *invest the time* in this
> until you justify WHY?

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.  But I have stronger arguments now...

> Not that I disagree with your efficiency reasoning or your pointer does
not
> do what promissed (I do not know that). It's not the point. There are a
lot
> of different smart pointers out there. Some people happily or not using
raw
> pointer. There are boost smart_ptr library that has a hell lot of happy
> users that do not bother with efficiency *that much*. To justify wide

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).

Who is taking decisions to validate boostlib official changes?  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.

> attention to non-conventional smart pointer interface, first thing to do
is
> to prove that conventional way does not work here while yours does. Only
in
> this case it has a future. And by "conventional" I mean Smart Pointer
design
> pattern with well defined interface, most closely (IMO) approximated in
> generic way by Policy-Based smart-pointer framework. And I believe that

I already proved it was 2 times faster than the already existing pointers
(only one memory allocation for one object).  What was left was to simplify
the syntax.

It is easy to integrate now because the object created is a pointer to non
template class xmm.  When xmm * would be detected then you will know it is
an object with an additional integer.  The integer could be used for:
reference counts, additional virtual tables, pointers, sizes, ... in the
future.

> namely the usage of such framework will become (becoming?) the
conventional
> way for defining custom (and regular) smart pointers.

We could partly specialize shared_ptr<> when ref<Type> type is used so that
the logic is maintained and will prevent sharing pointers with any other
type of type Type.

> Gennadiy.
>
> P.S. BTW What he word Policy mean in your context? I think it could be
> confusing if it different from more or less established by Andrei
> terminology.

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

> P.P.S. All the above is my personal opinion. Other boosters may correct me
> if I wrong.

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

The final <child> can easily be asserted at runtime thus be removed but I
prefer at compile-time.

Philippe A. Bouchard