[boost] Re: Proposals: p2m offsets, prebuild<>, squad_ptr<>(ofcourse)

From: David B. Held (dheld_at_[hidden])
Date: 2002-07-23 16:04:34

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:ahk9m0$dsr$1_at_main.gmane.org...
> [...]
> Sorry I wasn't specific enough.  What I meant is: does the object pointed
to
> needs to be properly wrapped using policy-based smart pointers (what are
> they anyways?)?

Read Modern C++ Design, by Andrei Alexandrescu. ;)

> [...]
> It's a widget with a disabled copy contructor.  The original constructor
> is important and cannot be wrapped.  You cannot also just rewrite it to
> make it derive from counted_base.  The only option left is a separate
> reference counter thus efficienty is dropping right now.  QListViewItem
> is another class with important constructor*s*.

Well, like Peter points out, you could wrap the entire interface (not my
first choice).  Or, you could use the "hideously inefficient" external
count.
The real question is whether the pointer-to-count, which I'm sure is what
you object to, is that expensive.  For entire listviews, it surely is not.
For
thousands of listview items, it may be a consideration.  I myself am a
big fan of the listview, and I have no qualms about filling one up with
thousands of items.  However, my typical listview record is maybe
80-120 bytes long.  I'm quite sure I wouldn't notice the loss of another 4
bytes to a count pointer.  However, one wonders why one would use a
smart pointer to a listview record.  I store listview data in an STL
container, and take iterators into it.

Dave