Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at