From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-23 18:59:19
"Jeff Flinn" <TriumphSprint2000_at_[hidden]> wrote in message
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> > It depends of your code and what semantics you want, but usually when
> > 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
> > 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
> use these containers.
Performance is not the only reason for using them (and as I said, it all
depends on your app). It's just more convenient
to read your program, it gives a clean feel of OO. I can image quite a few
beginners strugling with C++ syntax and
having a bit funny syntax just adds to that. For me it matters to...I would
like to focus on the program, not the syntax.
> I'd have to keep track of a 4th set of behaviours in
> dealing with container ownership issues.
what's the three first?
>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
> and have quite high performance requirements.
I have not experienced that exactly either, but I'm confident that such
applications do exists.
If you have a 1 milion polymophic objects and extra 8-12 bytes per object
could easily damage cache hit rates etc.
Even though it is wrong to focus on performance most of the time, the zero
overhead principle is a hallmark of C++.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk