From: David Abrahams (dave_at_[hidden])
Date: 2003-10-21 06:20:25
"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 easier
> 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 (for
> 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 implementation
> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk