Re: [boost] Re: Re: Logical constness of intrusive_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-19 05:04:54

From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:018501c22dac$ff373c30$1d00a8c0_at_pdimov2...
> > >
> > > I understand.  And the constness of intrusive_ptr_add_ref ultimately
> > relies on the constness of the count object, when there is one.  If
there
> > are valid reasons to have the const object be either const or non-const,
I
> > suppose the choice sould be passed up to the user.
> >
> > The choice _is_ left to the user. :-)
>
> Yes, technically it is, but not in a convenient fashion, since he would
need to create his own mutable counted_base.  Hence your smile, I presume.
I think that <T const> support is quite important, and so counted_base
should have its count mutable (with associated changes to free functions),
<

This comes at a cost. counted_base::release() const implies
counted_base::dispose() const. The function that dispose() performs is to
release any resources managed by the object. Hence, these resources would
need to be made mutable, and const correctness goes MIA.

> or there should be two counted_base-style classes provided.

Possible, but not strictly necessary. counted_base is provided since it is
an important bridge between intrusive_ptr and shared_ptr; if it weren't
provided, the user wouldn't be able to define it.

The "other" counted_base can be defined by the user, since there is nothing
special about it. It would be convenient to have it, of course, if there is
demand for a standard counted base with const addref/release methods.

> What's your plan for gathering enough information to make a decision on
how to proceed?

My "highly scientific" plan is:

1. Replace all of my intrusively counted pointers with
boost::intrusive_ptr<>. See if any problems surface (none so far; I've no
need of intrusive_ptr<T const>.)

2. Wait for feedback from intrusive_ptr users (if there are any.)