[boost] Re: Re: shifted_ptr decisions

From: Philippe A. Bouchard (philippe_at_[hidden])
Date: 2003-10-21 17:02:25

"Gregory Colvin" <gregory.colvin_at_[hidden]> wrote:

[...]

> >> - I have found an acceptable keyword to replace the "new" paradox:
> >
> > Paradox?
>
> Paradigm?

Exactly, the "new" paradigm.

[...]

> > The antonym of "record" is "erase".

"erase" is a synonym to "delete" ;)

> > 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.

Ok, I wasn't awared.  It's just that I liked the idea of having an operator
returning an auto_ptr instead of a raw pointer and this is what record<> was
doing.

[...]

> > 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);

Yes my apologies for the syntax.  I wanted to point out the allocations
routines mainly.

> >> 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?

Like Gregory was mentionning, "paradigm" makes more sense.  I was referring
to "paradox" because placement new is in fact an explicit constructor but
act as an allocator.

Philippe