[boost] Re: Formal Review request: Pointer Container Library

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2003-12-23 08:52:33

Thorsten,

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:bs85vf$s0o$1_at_sea.gmane.org...

 ...
>
> >or
> > bind:
> >       for_each( svec.begin(), svec.end(), bind(&Poly::foo,_1) );
>
> does bind really works with smart pointers?

Yes. I use this form extensively.

>
> > Yes, I read the advantages and they sound good; I just think you need an
> > example to show them off
>
> I'll think about adding them.
>
> >(and perhaps some benchmarks as you say it should
> > be quicker and use less memory than smart pointers).
>
> It depends of your code and what semantics you want, but usually when
having
> a big bunch of polymophic objects,
> it is a simple fact. You can also check NTL's benchmarks or look at the
> smart pointer timings/memory usage compared to
> naked pointers. Regarding memory,
> if you objects are big, then the memory overhead will of course be small,
> but if your objects are small it will be very big.

A couple of years ago I would have been a real advocate for this facility.
Now having become quite comfortable with shared_ptr, I would be reluctant to
use these containers. I'd have to keep track of a 4th set of behaviours in
dealing with container ownership issues. It is very atypical that I use
shared_ptr only because I want to store/remove pointers safely in/from a
container. Shared_ptr permeates the design well beyond container storage.
Profiling has never led to shared_ptr as a bottleneck. The applications I
deal with while themselves not real-time - interact with real-time software
and have quite high performance requirements.

Just my $0.02.

-----------------
Jeff Flinn
Applied Dynamics, International