$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-07 07:27:00
From: "Gennadiy Rozental" <rogeeff_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:005001c1f4f2$5c989110$1d00a8c0_at_pdimov2...
> > > a. Storage policy should answer the question: "HOW to store, access,
> > copy
> > > and release the resource".
> > > b. Ownership policy should answer the question: "WHEN to release the
> > > resource".
> >
> > This is a good separation, but how do you apply it to COM-style
intrusive
> > counted, self-deleting objects?
>
> There is no contradiction here. Look into proposed Ownership/Storage
> policies interface. I did not say that they could not share information
> storage (like with intrusive reference counting), what I meant is logic
> separation.
I didin't say anything about a contradiction. I asked a question.
> > > I do support intrusive reference counting through traits. I believe it
> > more
> > > flexible.
> >
> > In what ways is it more flexible?
> >
>
> As far as I understand boost::shared_ptr support for intrusive ref.
counting
> rely on the fact that user type inherit counted_base. I may be convinient,
> but for one: it not generic enough to cover all the cases (COM-style is
one
> example), and for two: in some cases I can't afford usind dynamic
binding,
> so I would prefer compile time one.
Why wouldn't you use your own framework to make a COM smart pointer for
this? Consider what happens when you forget to specialize the traits class
for some COM interface.