From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-10-21 15:14:49
On Tuesday, Oct 21, 2003, at 05:20 America/Denver, David Abrahams wrote:
> "Philippe A. Bouchard" <philippeb_at_[hidden]> writes:
>> Hi people,
>> I have made some decisions upon shifted_ptr. I am going to finish
>> documenting by the end of the week because I am sure at 100% it will
>> be ok:
>> - I am going to remove ownership;
>> - I am going to use counted_base instead if shifted_header::count for
>> shared_ptr<> casts;
>> - I have found an acceptable keyword to replace the "new" paradox:
>> "record<T>(...)"... the antonym of "delete";
> I don't know about everyone else, but that name makes no sense to me.
> The antonym of "record" is "erase".
> Your function should have a name which indicates that it's going to
> make a shifted_ptr and not something else. Surely we'll want to do
> the same thing with auto_ptr some day.
>> - I am not going to implement the extra counter to "indicator" nodes
>> those who know what I am talking about) because I do not have enough
>> ressources to distinguish heap / stack variables in a standard way.
>> So the smart pointers will look like the following:
>> shared_ptr<int> p = new int(9);
> I don't think so. The explicit constructor means you must write:
> shared_ptr<int> p(new int(9));
>> shifted_ptr<int> q = record<int>(9);
>> p(q); // Ok
>> q(p); // You decide whether it is worth the complexity of its
>> Please note that I didn't wanted to use "make" or "create" because
>> those are
>> used too much frequently as for the "new" paradox.
> ``as for the "new" paradox''
> makes no sense to me either. Would you mind rephrasing?
> Dave Abrahams
> Boost Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk