RE: [boost] Re: Re: Proposal: Efficient Pointers

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2002-07-18 05:12:25

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Philippe A. Bouchard
> "Sam Partington" <Sam.Partington_at_[hidden]> wrote in message

> > And personally I would not be happy using any kind of smart
> pointerr that
> > could potentially "lose" elements just because I had it in a container,
> and
> > then some months later, someone (more likely than not me) forgets or is
> > unaware of the side effects of the ptr, and passes the container to an
> > algorithm.
>
> You could for example:
> - read a file using list<>
> - transform list<> into vector<>
> - (add, remove, swap)^n
> - mark interesting lines using 'entry *' whom could be considered
> iterators
> - save the file
> - destruction won't be a problem now
Yes, I know I can do that, you didn't answer my question.  I can do that
with smart_ptr, I could do it with intrusive ptr, but, supposing you add an
extra stage.

- read a file using list<>
- transform list<> into vector<>
- (add, remove, swap)^n
- mark interesting lines using 'entry *' whom could be considered iterators
-> sort the vector
- save the file
- destruction won't be a problem now

except that now half of what was in the file has either disappearred, gpf'd,
or gone the way of the undefined.

> > Then with squad_ptr, firstly I don't see the significance of the name to
> be
> > honest, and  I most certainly don't like the semantics, and I
> fail to see
> > that it would necessarily be significantly faster than shared_ptr.
>
> It was named fdi::shared_ptr<> in the beginning and then renamed to
> fdi::squad_ptr<> to avoid name clashes.

yes, I saw you change the name, but why 'squad'?

> > Perhaps if you could profile an example using both boost::shared_ptr and
> > squad_ptr, then we could better judge if the benefits outweigh the
> > trade-offs in certain situations.
> Well we don't really need a profile if we can simply calculate it:
> O(mutable_ptr(add(), remove(), swap()) * n) < O(shared_ptr(add(),
> remove(),
> swap()) * n)
No, thats not what I said.  Yes, I can see mutable_ptr is going to be faster
than shared_ptr, but I said squad_ptr and shared_ptr.  and yes, I can also
see that squad is probably going to be faster shared, smaller too.  But I
could go back to using raw *'s all over the place - they are clearly the
most efficient - but I don't because the performance increase is not enough
to trade off the benefits of a smart pointer.

At the end of the day my users want a program that works right more than a
program that works quicker, mutable_ptr seems like a good way to ensure that
this doesn't happen.  And to me squad_ptr looks like a nightmare of
obfuscated code, which is going to be a nightmare of debugging (can you
imagine every time you want to have a look at an object, you're going to
have to cast the char[] to your object in a watch window - no thanks).

So the questions stands, how much of a performance increase is squad_ptr
going to give me?  in compared to shared_ptr and intrusive_ptr?

> If you're program is well designed and properly use a combinaison of
> mutable_ptr<> and * you will outstand shared_ptr<>.

Thats ok then because my programs are always perfectly designed, and I never
ever forget anything.

ahem!

sam