From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-27 08:09:45
"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
> "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> > 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
> do what promissed (I do not know that). It's not the point. There are a
> of different smart pointers out there. Some people happily or not using
> 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
> attention to non-conventional smart pointer interface, first thing to do
> to prove that conventional way does not work here while yours does. Only
> this case it has a future. And by "conventional" I mean Smart Pointer
> 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
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
> namely the usage of such framework will become (becoming?) the
> 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.
> 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
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"))
shared_ptr< gc<parent> > p = new (new (xmm) child("John", "McInnis"))
The final <child> can easily be asserted at runtime thus be removed but I
prefer at compile-time.
Philippe A. Bouchard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk