|
Boost : |
From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2002-07-17 08:18:02
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.
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.
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.
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.
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.
Just my 2p.
Sam
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Philippe A. Bouchard
> Sent: 17 July 2002 10:39
> To: boost_at_[hidden]
> Subject: [boost] Re: Proposal: Efficient Pointers
<snip>
> mutable_ptr<> should have restricted usages for primitive operations like
> container copyings and destructions. Advantageous example:
>
> class entry
> {
> virtual ~entry() {}
> };
>
> class company : entry
> {
> string name;
> list< mutable_ptr<entry> > affected_contracts;
> };
>
> class scientist : entry
> {
> string name;
> };
>
> list< mutable_ptr<entry> > transactions;
>
>
> You can see here that you could read a file into a list<> and transform it
> into a vector<> when you know its final size. You'll also notice by
> yourself that destructions will be done cleanly.
>
> [...]
>
>
>
> Philippe A. Bouchard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk