[boost] Re: shifted_ptr decisions

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:

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