[boost] Re: Re: Proposal: Efficient Pointers

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-17 12:45:56

"Sam Partington" <Sam.Partington_at_[hidden]> wrote in message
news:NDBBIABHPAACPOAKLJBHEEJPDGAA.Sam.Partington_at_codescape.com...
> I may be missing the point here, but I don't see how using mutable_ptr in
> this example is any better than using shared_ptr, if its a performance
> issue, then it would have to be a massive performance increase for it to
> make any noticable difference over the file reading time. Or even just the
> cost of doing whatever your going to do with the thing you're pointing to.

It may be insignificant at construction time, but management of the pointers
will pay off: swapping, adding and removing entries will be done nearly
instantly.

> 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

It's not too much complicated to explain either; mutable_ptr<> and list<>
are an in memory representation of your configuration file and 'entry *'
will be iterators marking your entries.

> Side effects like that I don't want to be in the documents "use at your
own
> risk" I want them flattly disallowed by the compiler.
>
> This seems like too much of a pay off for what I can only imagine is a
> relatively small increase in performance.

The sizeof(mutable_ptr<>) is also smaller than sizeof(shared_ptr<>).  If
fact it's half of the size so containing those mutable_ptr<> will cost less.

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

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

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

Philippe A. Bouchard