Re: [boost] Re: shifted_ptr decisions

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 
>> easier
>> shared_ptr<> casts;
>> - I have found an acceptable keyword to replace the "new" paradox:
>
> Paradox?

Paradigm?

>
>> "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
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost