RE: [boost] smart pointer puzzle

From: Richard Damon \(E-mail\) (RDamon_at_[hidden])
Date: 2002-03-26 08:54:57

> -----Original Message-----
> From: boost-admin_at_[hidden]
> [mailto:boost-admin_at_[hidden]]On
> Behalf Of E. Gladyshev
> Sent: Monday, March 25, 2002 10:44 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] smart pointer puzzle
>
>
>
> > Boost shared_ptr as the shared_ptr does not have
> > total ownership of the
> > object. The definition of Boost's shared pointer
> > does not allow for your
> > style of shared ownership.
>
> The requirements don't force you to use
> the boost's implementation of smart pointers.
> On contrary it says "implement a smart pointer".
>

I missed that you did not need to use a "standard" smart pointer. You can
create a smart pointer class to do what you want but it will have, at least
in my opinion, some nasties which make it not as useful for a generic smart
pointer (see below for details)

> >
> > 2) You need a much smarter shared_ptr that can
> > reconnect to other copies
> > from the stored pointer, and if there is none to
> > remember that it does not
> > own it. A normal shared_ptr will not be smart enough
> > to do this due to the
> > overhead that will be added, as it requires the
> > keeping of a map of some
> > sort of values under controlled by all shared_ptrs
> > in the program.
>
> This is a real solution that conforms to
> all the requirements.  The requirements
> don't say anything about the overhead.
>
> But we can append our solution with something
> like this.
>
> The new real smart shared_pointer<> implies
> some overhead.  The significance of the
> overhead depends on the context where
> the shared_pointer<> is used.
> Assuming that our implementation of
> shared_pointer<> uses a logarithmic
> container like STL::map<> to map the plain pointers,
> the overhead can be estimated as X*log(N), where
> N is the average number of new objects created
> by the system per second (the new objects
> are controlled with shared_pointer<>),
> and X is the average number of new shared_pointer<>
> objects per second.  This way you'll get
> average overhead time per second.
>
> As you can see for a huge class of application
> the overhead is not significant.
>

You can cut down the overhead even more if you use a hashing map to do the
first level of lookup. There are two parts of the overhead, first we incur a
creation/deletion overhead for every new object put under control of the
smart pointer. The is also a lookup overhead every time it need to adopt a
raw pointer.

More importantly is a complexity overhead in the design. It need to have two
distinct ways of converting a raw pointer into a smart pointer. It need a
conversion which takes over control of the object to convert the output of
new into a smart pointer. It also need a conversion which does not take
control to be used inside of foo() when we do not want it to take control if
it does not already have control. This adds complexity to the interface and
potential for misuse.

>
> >
> > 4) You fire the designer who gave the impossible
> > specs.
>
> I really like this solution, LOL.
> But unfortunately we cannot justify it,
> the spec is possible.  You proved it yourself.
>

This was somewhat in joke, but if none of the above were acceptable I think
a good summary.

On another note, your spec does not deal with thread safety. IF both threads
are allowed to access the object then you are in danger of unexpected
results, and you can not make the smart pointer the one in charge of this,
as the C code does not use it. If the caller is not allowed to access  the
value until foo() is done then you are safe.

--
richard_damon_at_[hidden] (Redirector to current best)
rbrdamon_at_[hidden] (Home)
rdamon_at_[hidden] (Work)