[boost] ... Re: Re: Proposal: boost::pool fast pointer

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-01 15:59:38

Little comment...

> I think that BEFORE we debate the technical small-print of a "fast
pointer"
> proposal, we should first agree that there is some deficiency in the
current
> set of std and boost supplied smart pointers that desperately needs to be
> addressed. Gennadiy asked exactly this in an earlier message, and it was
> never answered (at least not to my satisfaction!). As I remember the
answer
> he got back eventually was (to paraphrase): "there is nothing that doesn't
> work, nothing that the current smart pointers won't do, this proposal is
> just more efficient...". Is effiecency alone enough to just yet another
> smart pointer? I believe the answer is "no", but I'm willing to be
> convinced... What I need is a simple, concise argument that details
exactly
> what "efficiency" benefits a new implementation can provide.

Well I'm sure it would help popularity for hypercubed multiprocessor
algorithms when perfection & efficienty are vital.  A pointer of size (int
*) is really really fast to copy because it is the length of a machine word.
Now imagine the advantage of implementing complex parallel algorithms with
those.  It's like a nuclear reaction compared to an anti-matter explosion;
it's doing a good job but with some little oddities here are there and could
be better.

Also, if you build a gigantic container using the list< mutable_ptr<type> >
and accelerate partial searches with many indexes like vector<type *> build
on top of the lists (to search names beginning with [A-C] for example), or
map<type *, int>, XListViewItem(..., type *), etc. it will always be smaller
and faster to work with and will show up with big containers merges,
splices, list<>::sorts BTW, *copies*, and will help to remove flickering
effects on graphical interfaces.

> As an aside, IF there are demonstrable efficiency benefits, then perhaps
the
> current crop of boost smart pointers can be altered or re-implemented to
> advantage...
>
> Thanks,
> David Brownstein

Is may be unusual for now but once you're used to it, you won't go back to
shared_ptr<>.  I'm targeting here advanced developers, not beginners and
this is why I would like mutable_ptr<> to be boost::pool related.

http://groups.yahoo.com/group/boost/files/ptr/

Thanks,

Philippe A. Bouchard

P.S.:
Another thing on flaws in the STL definitions regarding container
prerequists.  It seems they forget the main definition of a container:
container : something that holds things, especially for transport or
storage.

I don't see here nothing that says anything about the fact that copies of
the elements should be identical.  They should implement some pointer traits
and add quicksort() in <algorithm>.