From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-17 12:45:56
"Sam Partington" <Sam.Partington_at_[hidden]> wrote in message
> 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
> 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,
> 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
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
> 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
> 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk