Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-07-27 10:22:12


You still fighting windmills.

> > I would conclude the following: nobody what to *invest the time* in this
> > until you justify WHY?
>
> Agreed, but the 'why' implies 'perfection'.
No. At least not in this case. I don't bother at this stage, how perfect is
your solution.

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

That's why I don't like Java (BTW you are thinking like Java programmer in
this case: you need new feature - you introduce new slightly different
class).
Why introduce new (in terms of interface, list of features and so on) if
there is generic (proven?) way to write a custom smart pointers?

>
> Who is taking decisions to validate boostlib official changes?
Library author influenced by the community probably.

> I would like simply to know if other people agrees with my class (xmm)

I don't want to search an agreement about your implementation yet. First I
want to agree about idea.

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

No. No. You still fail to get the point. I don't bother (yet) how fast is
your pointer and how simple is an interface (once it is different from
conventional)
What I asked you to prove is: "to prove that conventional way does not work
here while yours does"

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

What are you talking about here. How its related to what I sad? I can't stop
myself from feeling that this discussion looks like broken phone.

>
> > 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 useful for different
> allocation technique; flexible enough.

I still did not get the definition what are these "pointer-based policies".
There are more or less established notion of "Policies" and "Traits" that I
know about. I could not tell what you mean.

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

How it's related to what I sad?

>
> Philippe A. Bouchard

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk