[boost] Re: Challenge: pool allocator

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 2000-03-06 06:20:40

From: Dave Abrahams [mailto:abrahams_at_[hidden]]
> 
> on 3/6/00 4:41 AM, Moore, Paul at Paul.Moore_at_[hidden] wrote:
> 
> You may be just focusing on things which are of concern to 
> you. To some people, the question of which shared_ptr implementation
> is more efficient is of critical importance, and I think rightly so.
> The issue of how to "release" ownership of an object once it has
> arrived in a standard container of smart pointers is probably also
> important [maybe some of the other discussion has been less
> relevant, but I've just ignored it ;) ]

Sorry if I gave the wrong impression. Most of the smart_ptr stuff has been a
little over my head. I was interpreting the discussions as being about how
to "fix" issues in the existing implementations (did I misread things?),
where I was advocating more of an attempt to document the differences and
provide both - with a recommended "for basic use" case for people who don't
need to worry about the issues.

I picked up this impression from the linked_ptr/shared_ptr discussion - it
seemed to me that efforts were being directed towards a choice or a merge,
rather than providing both.

This may just demonstrate the perils of skimming technical discussions...
:-)

> 
> > Am I not right in thinking that the final state of 
> > auto_ptr<> was a result of trying to be all things to all men?
> > Are we risking the same fate?
> 
> Not exactly. It was more due to the fact that all men would 
> think that it is all things, when in fact it is not. ;)

OK, rephrase that then. Is the biggest problem with auto_ptr<> that people
don't understand the issue it is designed to solve (and the limits to its
target problem area)? Can we avoid the same problem?

> > PS I'd like to see more work on adding new facilities, rather
> > than endlessly refining existing ones - I like the recently posted 
> > interval arithmetic and range set classes. More of the same, please!
> 
> Yes, there's lots missing. Please feel free to propose things 
> which you would like to see!

I hope that's what rational<> was. You'll see some indications of my
philosophy in that - the class is designed for *basic* use, and is
definitely not suitable for specialist use. In fact, I'd freely admit that
the behaviour of rational<> near its limits is dreadfully obscure and
unhelpful. But it's not meant to be used like that...

But you are right - I'll get back to offering code. My next likely project
is a simple (a la rational) unlimited-precision integer class. Emphasising
usability over raw performance, and aimed at people who don't want to risk
hitting 32-bit limits, but NOT people who routinely work with huge numbers.
Would people be interested?

Paul.