Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-23 18:59:19

"Jeff Flinn" <TriumphSprint2000_at_[hidden]> wrote in message
> Thorsten,
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> news:bs85vf$s0o$


> > 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
> > 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, gregod at, cpdaniel at, john at