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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk