------=_Part_8473_526458.1373229804437
Content-Type: text/plain; charset=ISO-8859-1

Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by
value.

Consider "old C++" code:

void process(Widget* w){
  w->do_something();
  delete w; // nasty run-time error: w will be deleted again
}

void main(){
  Widget* w=new Widget();
  process(w);
  delete w;
}

Let's try to rewrite it with std::unique_ptr<>:

//void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be
passed by value!
void process(unique_ptr<Widget>& w){ // extra level of indirection -
potentially inefficient
  w->do_something();
  delete w; // syntax error now - good
}

void main(){
  auto w=make_unique<Widget>();
  process(w);
  // delete w; - no longer needed
}

Solution: Add a new class std::nonowning_ptr<> representing a pointer that
does not own a resource (it plays a similar role as weak_ptr<> to
shared_ptr<>).

Requirements:
  Template std::nonowning_ptr<T*> wraps T*, and is:

  - constructable and assignable from T*, nullptr, std::unique_ptr<T*>, and
another std::nonowning_ptr<T*>, with the appropriate type casts allowed,
`const' handled properly, and `explicit' used wherever needed

  - application of `delete' to it should trigger a syntax error

  - has the usual pointer operations: *, ->, comparisons, explicit operator
bool()

  - has the get() member function yielding the stored raw pointer

  - a partial specialisation for T[] might be appropriate

  - maybe something else - suggestions are welcome.

Now the code looks like:

// the nonowning_ptr<Widget> parameter, unlike Widget*, makes it clear
// that the function will not free the resource - good for readability
void process(nonowning_ptr<Widget> w){ // no extra indirection - good
  w->do_something();
  delete w; // still a syntax error - good
}

void main(){
  auto w=make_unique<Widget>();
  process(w); // conversion to nonowning_ptr - this is 0-overhead
  // delete w; - no longer needed
}

Drawbacks: the resource could be used via nonowning_ptr<Widget> after the
parent unique_ptr freed it - but that has forever been the case for raw
pointers.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_8473_526458.1373229804437
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Problem: annoyingly, std::unique_ptr&lt;&gt; cannot be passed to a fun=
ction by value.</div><div>&nbsp;</div><div>Consider "old C++" code:</div><d=
iv>&nbsp;</div><div>void process(Widget* w){</div><div>&nbsp; w-&gt;do_some=
thing();</div><div>&nbsp; delete w; // nasty run-time error: w will be dele=
ted again</div><div>}</div><div>&nbsp;</div><div>void main(){</div><div>&nb=
sp; Widget* w=3Dnew Widget();</div><div>&nbsp; process(w);</div><div>&nbsp;=
 delete w;</div><div>}</div><div>&nbsp;</div><div>Let's try to rewrite it w=
ith std::unique_ptr&lt;&gt;:</div><div>&nbsp;</div><div><div><div>//void pr=
ocess(unique_ptr&lt;Widget&gt; w){ // problem - unique_ptr cannot be passed=
 by value!</div><div>void process(unique_ptr&lt;Widget&gt;&amp; w){ // extr=
a level of indirection&nbsp;- potentially inefficient</div>&nbsp; w-&gt;do_=
something();</div><div>&nbsp; delete w; // syntax error now - good</div><di=
v>}</div><div>&nbsp;</div><div>void main(){</div><div>&nbsp; auto w=3Dmake_=
unique&lt;Widget&gt;();</div><div>&nbsp; process(w);</div><div>&nbsp; // de=
lete w; - no longer needed</div><div>}</div></div><div>&nbsp;</div><div>Sol=
ution: Add a new class  std::nonowning_ptr&lt;&gt; representing a pointer t=
hat does not own a resource (it&nbsp;plays a similar role as weak_ptr&lt;&g=
t; to shared_ptr&lt;&gt;).</div><div>&nbsp;</div><div>Requirements: </div><=
div>&nbsp; Template std::nonowning_ptr&lt;T*&gt; wraps T*, and is:</div><di=
v>&nbsp;</div><div>&nbsp; - constructable and assignable&nbsp;from T*, null=
ptr, std::unique_ptr&lt;T*&gt;, and another std::nonowning_ptr&lt;T*&gt;, w=
ith the appropriate type casts allowed, `const' handled properly, and `expl=
icit' used wherever needed</div><div>&nbsp;</div><div>&nbsp; - application =
of `delete' to it should trigger a syntax error</div><div>&nbsp;</div><div>=
&nbsp; - has the usual pointer operations: *, -&gt;, comparisons, explicit =
operator bool()</div><div>&nbsp;</div><div>&nbsp; - has the get() member fu=
nction yielding the stored raw pointer</div><div><div>&nbsp;</div><div>&nbs=
p;&nbsp;- a partial specialisation for T[] might be appropriate</div></div>=
<div>&nbsp;</div><div>&nbsp;&nbsp;- maybe something else - suggestions are =
welcome.</div><div>&nbsp;</div><div>Now the code looks like:</div><div>&nbs=
p;</div><div>// the nonowning_ptr&lt;Widget&gt;&nbsp;parameter, unlike Widg=
et*,&nbsp;makes it clear</div><div>// that the function will not free the r=
esource - good for readability</div><div><div>void process(nonowning_ptr&lt=
;Widget&gt; w){ // no extra&nbsp;indirection&nbsp;- good</div>&nbsp; w-&gt;=
do_something();<div>&nbsp; delete w; // still a syntax error&nbsp;- good</d=
iv><div>}</div><div>&nbsp;</div><div>void main(){</div><div><div>&nbsp; aut=
o w=3Dmake_unique&lt;Widget&gt;();</div>&nbsp; process(w); // conversion to=
 nonowning_ptr -&nbsp;this is 0-overhead</div><div>&nbsp; // delete w; - no=
 longer needed</div><div>}</div></div><div>&nbsp;</div><div>Drawbacks: the =
resource could be used via nonowning_ptr&lt;Widget&gt; after the parent uni=
que_ptr freed it - but that has forever been the case for raw pointers.</di=
v>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_8473_526458.1373229804437--

.

--047d7b6d7a306d848a04e1033a22
Content-Type: text/plain; charset=ISO-8859-1

On 7 July 2013 15:43, <Victor.Khomenko@ncl.ac.uk> wrote:

>
>
>
> Solution: Add a new class std::nonowning_ptr<> representing a pointer that
> does not own a resource (it plays a similar role as weak_ptr<> to
> shared_ptr<>).
>

-1

If you are already editing code to take advantage of this, just don't call
delete.  Heck, good code rarely calls delete *anywhere* except in the
deleter of a smart pointer.

It seems like a lot of complexity (for users and not just the library) with
very little benefit.  Of course, if there are existing implementations with
years of experience already, I'm willing to reconsider.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7b6d7a306d848a04e1033a22
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 7 July 2013 15:43,  <span dir=3D"ltr">&lt;<a href=3D"mailto:Victor.Khome=
nko@ncl.ac.uk" target=3D"_blank">Victor.Khomenko@ncl.ac.uk</a>&gt;</span> w=
rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div>=A0</div><div>Solution: Add a new class  std::nonowning_ptr&lt=
;&gt; representing a pointer that does not own a resource (it=A0plays a sim=
ilar role as weak_ptr&lt;&gt; to shared_ptr&lt;&gt;).</div></blockquote><di=
v>

<br>-1<br><br>If you are already editing code to take advantage of this, ju=
st don&#39;t call delete.=A0 Heck, good code rarely calls delete *anywhere*=
 except in the deleter of a smart pointer.<br><br>It seems like a lot of co=
mplexity (for users and not just the library) with very little benefit.=A0 =
Of course, if there are existing implementations with years of experience a=
lready, I&#39;m willing to reconsider.<br clear=3D"all">

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6d7a306d848a04e1033a22--

.

--047d7bea3fce72ed3b04e1036376
Content-Type: text/plain; charset=ISO-8859-1

On 7 July 2013 23:43, <Victor.Khomenko@ncl.ac.uk> wrote:

> Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by
> value.
>

Yes it can.


>
> Consider "old C++" code:
>
> void process(Widget* w){
>   w->do_something();
>   delete w; // nasty run-time error: w will be deleted again
> }
>
> void main(){
>   Widget* w=new Widget();
>   process(w);
>   delete w;
> }
>
> Let's try to rewrite it with std::unique_ptr<>:
>
> //void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be
> passed by value!
>
>
void process(unique_ptr<Widget>& w){ // extra level of indirection -
> potentially inefficient
>   w->do_something();
>   delete w; // syntax error now - good
> }
>
> void main(){
>   auto w=make_unique<Widget>();
>   process(w);
>   // delete w; - no longer needed
> }
>

If you change the call process(w); to process(move(w)); it works just fine,
even when process takes a unique_ptr
by value.


>
> Solution: Add a new class std::nonowning_ptr<> representing a pointer that
> does not own a resource (it plays a similar role as weak_ptr<> to
> shared_ptr<>).
>

See "A Proposal for the World's Dumbest Smart Pointer",
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bea3fce72ed3b04e1036376
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 July 2013 23:43,  <span dir=3D"ltr">&lt;<a href=3D"mailto:Vict=
or.Khomenko@ncl.ac.uk" target=3D"_blank">Victor.Khomenko@ncl.ac.uk</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>Problem: annoyingly,=
 std::unique_ptr&lt;&gt; cannot be passed to a function by value.</div></bl=
ockquote>
<div><br></div><div>Yes it can.<br>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div>=A0</div><div>Consider &quot;old C++&quot; code=
:</div>
<div>=A0</div><div>void process(Widget* w){</div><div>=A0 w-&gt;do_somethin=
g();</div><div>=A0 delete w; // nasty run-time error: w will be deleted aga=
in</div><div>}</div><div>=A0</div><div>void main(){</div><div>=A0 Widget* w=
=3Dnew Widget();</div>
<div>=A0 process(w);</div><div>=A0 delete w;</div><div>}</div><div>=A0</div=
><div>Let&#39;s try to rewrite it with std::unique_ptr&lt;&gt;:</div><div>=
=A0</div><div><div><div>//void process(unique_ptr&lt;Widget&gt; w){ // prob=
lem - unique_ptr cannot be passed by value!<br>
=A0</div></div></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div><div><div>void process(unique_ptr&lt;Widget&gt;&amp; w){ //=
 extra level of indirection=A0- potentially inefficient</div>
=A0 w-&gt;do_something();</div><div>=A0 delete w; // syntax error now - goo=
d</div><div>}</div><div>=A0</div><div>void main(){</div><div>=A0 auto w=3Dm=
ake_unique&lt;Widget&gt;();</div><div>=A0 process(w);</div><div>=A0 // dele=
te w; - no longer needed</div>
<div>}</div></div></blockquote><div><br></div><div>If you change the call p=
rocess(w); to process(move(w)); it works just fine, even when process takes=
 a unique_ptr<br>by value.<br>=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
<div>=A0</div><div>Solution: Add a new class  std::nonowning_ptr&lt;&gt; re=
presenting a pointer that does not own a resource (it=A0plays a similar rol=
e as weak_ptr&lt;&gt; to shared_ptr&lt;&gt;).</div></blockquote><div><br></=
div>
<div>See &quot;A Proposal for the World&#39;s Dumbest Smart Pointer&quot;,<=
br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf=
">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf</a><br><br>
<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea3fce72ed3b04e1036376--

.

I'd rather not. Widget* needs to become equivalent to
nonowning_ptr<Widget> in idiomatic C++11.

On Sun, Jul 7, 2013 at 1:43 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by
> value.

Pass the result of std::unique_ptr<>::get()

> Consider "old C++" code:
>
> void process(Widget* w){
>   w->do_something();
>   delete w; // nasty run-time error: w will be deleted again
> }
>
> void main(){
>   Widget* w=new Widget();
>   process(w);
>   delete w;
> }
>
> Let's try to rewrite it with std::unique_ptr<>:
>
> //void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be
> passed by value!
> void process(unique_ptr<Widget>& w){ // extra level of indirection -
> potentially inefficient
>   w->do_something();
>   delete w; // syntax error now - good

Seeing "delete" is a yellow flag in idiomatic C++11. Instead, process
should take a Widget* or Widget& and know not to delete it, just like
you know not to delete the address of a reference. Perhaps compilers
will start warning about this someday.

> }
>
> void main(){
>   auto w=make_unique<Widget>();
>   process(w);
>   // delete w; - no longer needed
> }
>
> Solution: Add a new class std::nonowning_ptr<> representing a pointer that
> does not own a resource (it plays a similar role as weak_ptr<> to
> shared_ptr<>).
>
> Requirements:
>   Template std::nonowning_ptr<T*> wraps T*, and is:
>
>   - constructable and assignable from T*, nullptr, std::unique_ptr<T*>, and
> another std::nonowning_ptr<T*>, with the appropriate type casts allowed,
> `const' handled properly, and `explicit' used wherever needed
>
>   - application of `delete' to it should trigger a syntax error
>
>   - has the usual pointer operations: *, ->, comparisons, explicit operator
> bool()
>
>   - has the get() member function yielding the stored raw pointer
>
>   - a partial specialisation for T[] might be appropriate
>
>   - maybe something else - suggestions are welcome.
>
> Now the code looks like:
>
> // the nonowning_ptr<Widget> parameter, unlike Widget*, makes it clear
> // that the function will not free the resource - good for readability
> void process(nonowning_ptr<Widget> w){ // no extra indirection - good
>   w->do_something();
>   delete w; // still a syntax error - good
> }
>
> void main(){
>   auto w=make_unique<Widget>();
>   process(w); // conversion to nonowning_ptr - this is 0-overhead
>   // delete w; - no longer needed
> }
>
> Drawbacks: the resource could be used via nonowning_ptr<Widget> after the
> parent unique_ptr freed it - but that has forever been the case for raw
> pointers.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

------=_Part_9446_9885638.1373304749211
Content-Type: text/plain; charset=ISO-8859-1


On Monday, July 8, 2013 6:17:28 PM UTC+1, Nevin ":-)" Liber wrote:


> If you are already editing code to take advantage of this, just don't call
> delete.  Heck, good code rarely calls delete *anywhere* except in the
> deleter of a smart pointer.
>

I don't understand your comment - one simply cannot call delete for
nonowning_ptr, this will cause syntax error. The delete in the example was
to demonstrate how rewriting of "old c++" code turns a run-time error to a
syntax one.

Also, the main point of nonowning_ptr is to solve the problem of passing
unique_ptr to functions without the overhead of an extra level of
indirection.



> It seems like a lot of complexity (for users and not just the library)
> with very little benefit.  Of course, if there are existing implementations
> with years of experience already, I'm willing to reconsider.
>

The implementation is very similar to unique_ptr, just simpler (no deleter).

Victor.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_9446_9885638.1373304749211
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Monday, July 8, 2013 6:17:28 PM UTC+1, Nevin ":-)" Liber wrote:<div>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div class=3D"gmail_quote"><div>If=
 you are already editing code to take advantage of this, just don't call de=
lete.&nbsp; Heck, good code rarely calls delete *anywhere* except in the de=
leter of a smart pointer.<br></div></div></blockquote><div>&nbsp;</div><div=
>I don't understand your comment -&nbsp;one simply cannot call delete for n=
onowning_ptr, this will cause syntax error. The delete in the example was t=
o demonstrate how rewriting of "old c++" code turns a run-time error to a s=
yntax one.</div><div>&nbsp;</div><div>Also, the main point of nonowning_ptr=
 is to solve the problem of passing unique_ptr to functions without the ove=
rhead of an extra level of indirection.</div><div>&nbsp;</div><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div class=3D"gmail_quote"><div>It seems l=
ike a lot of complexity (for users and not just the library) with very litt=
le benefit.&nbsp; Of course, if there are existing implementations with yea=
rs of experience already, I'm willing to reconsider.<br clear=3D"all"></div=
></div></blockquote><div>&nbsp;</div><div>The implementation is very simila=
r to unique_ptr, just simpler (no deleter).</div><div>&nbsp;</div><div>Vict=
or.</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_9446_9885638.1373304749211--

.

On Mon, Jul 8, 2013 at 7:32 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> Also, the main point of nonowning_ptr is to solve the problem of passing
> unique_ptr to functions without the overhead of an extra level of
> indirection.

Wait, *what* problem exactly? The only situation where you have that
problem is when you bring it upon yourself. It does not arise
naturally.

Functions that deal with ownership needs to take ownership-related
arguments. Functions that don't deal with ownership *must not* take
ownership-related arguments.

Functions that operate on a T but don't deal with ownership should
have the same signature as usual: f(T&) or f(T const&), or similar
with pointers. C++11 or unique_ptrs don't change that. Functions that
operate on a T but don't deal with ownership are just *normal*. You
pass them references to objects, not ownership handles.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--047d7bdc93960d9c2404e103b187
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 20:41, Martinho Fernandes <martinho.fernandes@gmail.com>wrote:

>
> Functions that operate on a T but don't deal with ownership should
> have the same signature as usual: f(T&) or f(T const&), or similar
> with pointers. C++11 or unique_ptrs don't change that. Functions that
> operate on a T but don't deal with ownership are just *normal*. You
> pass them references to objects, not ownership handles.
>
>
>
We have handle that completely transfers/holds ownership (unique_ptr), we
have a handle
that shares ownership (shared_ptr), but we have no handle that doesn't
transfer/hold ownership
at all. T* does all of that and none of that depending on how people use
it, and fails to convey
the semantics at a glance in a function signature. Therefore I think it
would be a good idea
to add what Walter Brown has proposed, aka a non-owning "smart" pointer.
Not to mention
that he has also proposed the other missing piece of our puzzle, aka the
value_ptr,
"A Preliminary Proposal for a Deep-Copying Smart Pointer",
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bdc93960d9c2404e103b187
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 20:41, Martinho Fernandes <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinho.fern=
andes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Functions that operate on a T but don&#39;t deal with ownership should<br>
have the same signature as usual: f(T&amp;) or f(T const&amp;), or similar<=
br>
with pointers. C++11 or unique_ptrs don&#39;t change that. Functions that<b=
r>
operate on a T but don&#39;t deal with ownership are just *normal*. You<br>
pass them references to objects, not ownership handles.<br>
<div class=3D""><div class=3D"h5"><br><br></div></div></blockquote><div><br=
></div><div>We have handle that completely transfers/holds ownership (uniqu=
e_ptr), we have a handle<br>that shares ownership (shared_ptr), but we have=
 no handle that doesn&#39;t transfer/hold ownership<br>
at all. T* does all of that and none of that depending on how people use it=
, and fails to convey<br>the semantics at a glance in a function signature.=
 Therefore I think it would be a good idea<br></div><div>to add what Walter=
 Brown has proposed, aka a non-owning &quot;smart&quot; pointer. Not to men=
tion<br>
that he has also proposed the other missing piece of our puzzle, aka the va=
lue_ptr,<br>&quot;A Preliminary Proposal for a Deep-Copying Smart Pointer&q=
uot;,<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n33=
39.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf</a><b=
r>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc93960d9c2404e103b187--

.

------=_Part_320_22086826.1373306180878
Content-Type: text/plain; charset=ISO-8859-1


>
> See "A Proposal for the World's Dumbest Smart Pointer",
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf
>
>
Ok, looks like I'm re-inventing the wheel. Thanks for pointing
this document out to me.

The current proposal does not have constructors/assignment from unique_ptr,
but they do mention the possibility of being aware of other pointers.

Anyway, no point to pursue this any further, let's kill the topic.

Victor.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_320_22086826.1373306180878
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div>See "A Proposal for the World's Dumbest Smart Pointer",<br><a href=
=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf" target=
=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n3514.=
<wbr>pdf</a><br><br></div></div></div></div></blockquote><div>&nbsp;</div><=
div>Ok, looks like I'm re-inventing the wheel. Thanks for pointing this&nbs=
p;document out to me.</div><div>&nbsp;</div><div>The current proposal does =
not have constructors/assignment from unique_ptr, but they do mention the p=
ossibility of being aware of other pointers.</div><div>&nbsp;</div><div>Any=
way, no point to pursue this any further, let's kill the topic.</div><div>&=
nbsp;</div><div>Victor.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_320_22086826.1373306180878--

.

--047d7b2e5290585e9e04e103c6c3
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 12:51, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
>
> We have handle that completely transfers/holds ownership (unique_ptr), we
> have a handle
> that shares ownership (shared_ptr), but we have no handle that doesn't
> transfer/hold ownership
> at all. T* does all of that and none of that depending on how people use
> it, and fails to convey
> the semantics at a glance in a function signature.
>

Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial to
implement) or unique_ptr (required a language change to implement) and is
fairly simple to implement.  Where is the existing practice to standardize?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7b2e5290585e9e04e103c6c3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 July 2013 12:51, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div><div><br></div></div><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D"im"><div><br></div></div><div>We have h=
andle that completely transfers/holds ownership (unique_ptr), we have a han=
dle<br>

that shares ownership (shared_ptr), but we have no handle that doesn&#39;t =
transfer/hold ownership<br>
at all. T* does all of that and none of that depending on how people use it=
, and fails to convey<br>the semantics at a glance in a function signature.=
</div></div></div></div></blockquote><div><br>Then why isn&#39;t such a thi=
ng in wide use?=A0 Unlike shared_ptr (not trivial to implement) or unique_p=
tr (required a language change to implement) and is fairly simple to implem=
ent.=A0 Where is the existing practice to standardize?<br clear=3D"all">

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b2e5290585e9e04e103c6c3--

.

--001a11c2c0ecddf4e904e103cc10
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 20:56, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 8 July 2013 12:51, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>>
>> We have handle that completely transfers/holds ownership (unique_ptr), we
>> have a handle
>> that shares ownership (shared_ptr), but we have no handle that doesn't
>> transfer/hold ownership
>> at all. T* does all of that and none of that depending on how people use
>> it, and fails to convey
>> the semantics at a glance in a function signature.
>>
>
> Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial
> to implement) or unique_ptr (required a language change to implement) and
> is fairly simple to implement.  Where is the existing practice to
> standardize?
>

Right here: http://qt-project.org/doc/qt-4.8/qpointer.html

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--001a11c2c0ecddf4e904e103cc10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 20:56, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On 8 Ju=
ly 2013 12:51, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:vi=
lle.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a=
>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">

<div dir=3D"ltr"><div><div><br></div></div><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><div><br></div></div><div>We have handle that co=
mpletely transfers/holds ownership (unique_ptr), we have a handle<br>

that shares ownership (shared_ptr), but we have no handle that doesn&#39;t =
transfer/hold ownership<br>
at all. T* does all of that and none of that depending on how people use it=
, and fails to convey<br>the semantics at a glance in a function signature.=
</div></div></div></div></blockquote></div><div><br>Then why isn&#39;t such=
 a thing in wide use?=A0 Unlike shared_ptr (not trivial to implement) or un=
ique_ptr (required a language change to implement) and is fairly simple to =
implement.=A0 Where is the existing practice to standardize?<br clear=3D"al=
l">
</div></div></blockquote><div><br></div><div>Right here: <a href=3D"http://=
qt-project.org/doc/qt-4.8/qpointer.html">http://qt-project.org/doc/qt-4.8/q=
pointer.html</a><br><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2c0ecddf4e904e103cc10--

.

On Mon, Jul 8, 2013 at 7:59 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>
>
> On 8 July 2013 20:56, Nevin Liber <nevin@eviloverlord.com> wrote:
>>
>> On 8 July 2013 12:51, Ville Voutilainen <ville.voutilainen@gmail.com>
>> wrote:
>>>
>>>
>>>
>>> We have handle that completely transfers/holds ownership (unique_ptr), we
>>> have a handle
>>> that shares ownership (shared_ptr), but we have no handle that doesn't
>>> transfer/hold ownership
>>> at all. T* does all of that and none of that depending on how people use
>>> it, and fails to convey
>>> the semantics at a glance in a function signature.
>>
>>
>> Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial
>> to implement) or unique_ptr (required a language change to implement) and is
>> fairly simple to implement.  Where is the existing practice to standardize?
>
>
> Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>

That looks like a weak_ptr.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--001a11c2ed4ac4c70f04e103efef
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 21:02, Martinho Fernandes <martinho.fernandes@gmail.com>wrote:

> >
> >
> > Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
> >
>
> That looks like a weak_ptr.
>
>
They have an actual weak_ptr here:
http://qt-project.org/doc/qt-4.8/qweakpointer.html.
The observation of deletion in QPointer may be weak-pointer-like, but it's
not otherwise
related to the shared_ptr counterpart they have, QSharedPointer. For the
things
we are discussing here, QPointers are used when people want to pass
non-owning
smart pointers around without passing ownership and to avoid the lack of
semantics
that T* suffers from. QPointer is restricted to QObjects, so it's not
exactly what
we're looking for.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--001a11c2ed4ac4c70f04e103efef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 21:02, Martinho Fernandes <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinho.fern=
andes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D""><div clas=
s=3D"h5">&gt;<br>
&gt;<br>
&gt; Right here: <a href=3D"http://qt-project.org/doc/qt-4.8/qpointer.html"=
 target=3D"_blank">http://qt-project.org/doc/qt-4.8/qpointer.html</a><br>
&gt;<br>
<br>
</div></div>That looks like a weak_ptr.<br>
<div class=3D""><div class=3D"h5"><br></div></div></blockquote><div><br></d=
iv><div>They have an actual weak_ptr here: <a href=3D"http://qt-project.org=
/doc/qt-4.8/qweakpointer.html">http://qt-project.org/doc/qt-4.8/qweakpointe=
r.html</a>.<br>
</div><div>The observation of deletion in QPointer may be weak-pointer-like=
, but it&#39;s not otherwise<br>related to the shared_ptr counterpart they =
have, QSharedPointer. For the things<br>we are discussing here, QPointers a=
re used when people want to pass non-owning<br>
smart pointers around without passing ownership and to avoid the lack of se=
mantics<br>that T* suffers from. QPointer is restricted to QObjects, so it&=
#39;s not exactly what<br>we&#39;re looking for.<br></div></div></div></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2ed4ac4c70f04e103efef--

.

On Mon, Jul 8, 2013 at 8:08 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>
>
> On 8 July 2013 21:02, Martinho Fernandes <martinho.fernandes@gmail.com>
> wrote:
>>
>> >
>> >
>> > Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>> >
>>
>> That looks like a weak_ptr.
>>
>
> They have an actual weak_ptr here:
> http://qt-project.org/doc/qt-4.8/qweakpointer.html.
> The observation of deletion in QPointer may be weak-pointer-like, but it's
> not otherwise
> related to the shared_ptr counterpart they have, QSharedPointer. For the
> things
> we are discussing here, QPointers are used when people want to pass
> non-owning
> smart pointers around without passing ownership and to avoid the lack of
> semantics
> that T* suffers from. QPointer is restricted to QObjects, so it's not
> exactly what
> we're looking for.

But would QPointer have use if it didn't have the ability to check
validity and was purely for semantic value? I see the validity check
as an interesting feature, but I don't see much value in the same
thing stripped of that ability.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--047d7bea3fce13c08e04e10422cf
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 21:18, Martinho Fernandes <martinho.fernandes@gmail.com>wrote:

> But would QPointer have use if it didn't have the ability to check
> validity and was purely for semantic value? I see the validity check
>

Yes (imho), as would a non-owning "smart" pointer in general, because it
tells
people at-a-glance what the ownership transfer (or more precisely, the lack
of
it) is. T* doesn't do that. T& doesn't work for cases when the incoming
value
may be non-existent. optional<reference_wrapper<T>> comes close, if we
want to look for a decent alternative.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bea3fce13c08e04e10422cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 21:18, Martinho Fernandes <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinho.fern=
andes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">But would QPointer have use if it didn&#39;t=
 have the ability to check<br>
validity and was purely for semantic value? I see the validity check<br></b=
lockquote><div><br></div><div>Yes (imho), as would a non-owning &quot;smart=
&quot; pointer in general, because it tells<br>people at-a-glance what the =
ownership transfer (or more precisely, the lack of<br>
it) is. T* doesn&#39;t do that. T&amp; doesn&#39;t work for cases when the =
incoming value<br></div><div>may be non-existent. optional&lt;reference_wra=
pper&lt;T&gt;&gt; comes close, if we<br>want to look for a decent alternati=
ve.<br>
</div><div><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea3fce13c08e04e10422cf--

.

--047d7bdc9396efda6f04e10427f9
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 21:22, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
> Yes (imho), as would a non-owning "smart" pointer in general, because it
> tells
> people at-a-glance what the ownership transfer (or more precisely, the
> lack of
> it) is. T* doesn't do that. T& doesn't work for cases when the incoming
> value
> may be non-existent. optional<reference_wrapper<T>> comes close, if we
> want to look for a decent alternative.
>
>
>
Then again, optional<reference_wrapper<T>> doesn't behave like a pointer,
and neither does optional<T*>. They protect against attempts to delete,
but they lack the other pointer-like syntax characteristics.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bdc9396efda6f04e10427f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 21:22, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div>Yes (imho), as would a non-owning &quot=
;smart&quot; pointer in general, because it tells<br>
people at-a-glance what the ownership transfer (or more precisely, the lack=
 of<br>
it) is. T* doesn&#39;t do that. T&amp; doesn&#39;t work for cases when the =
incoming value<br></div><div>may be non-existent. optional&lt;reference_wra=
pper&lt;T&gt;&gt; comes close, if we<br>want to look for a decent alternati=
ve.<br>

</div><div><br><br></div></div></div></div></blockquote><div><br></div><div=
>Then again, optional&lt;reference_wrapper&lt;T&gt;&gt; doesn&#39;t behave =
like a pointer,<br>and neither does optional&lt;T*&gt;. They protect agains=
t attempts to delete,<br>
but they lack the other pointer-like syntax characteristics. <br></div></di=
v><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc9396efda6f04e10427f9--

.

On Mon, Jul 8, 2013 at 11:02 AM, Martinho Fernandes
<martinho.fernandes@gmail.com> wrote:
> On Mon, Jul 8, 2013 at 7:59 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>>
>>
>> On 8 July 2013 20:56, Nevin Liber <nevin@eviloverlord.com> wrote:
>>>
>>> On 8 July 2013 12:51, Ville Voutilainen <ville.voutilainen@gmail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> We have handle that completely transfers/holds ownership (unique_ptr), we
>>>> have a handle
>>>> that shares ownership (shared_ptr), but we have no handle that doesn't
>>>> transfer/hold ownership
>>>> at all. T* does all of that and none of that depending on how people use
>>>> it, and fails to convey
>>>> the semantics at a glance in a function signature.
>>>
>>>
>>> Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial
>>> to implement) or unique_ptr (required a language change to implement) and is
>>> fairly simple to implement.  Where is the existing practice to standardize?
>>
>>
>> Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>>
>
> That looks like a weak_ptr.

Ah, Chromium has a "WeakPtr" that serves the same purpose:
https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/weak_ptr.h.

It's very different from a std::weak_ptr in that the underlying object
doesn't need to be refcounted, but it's very useful in its own right.
It's definitely *not* the same thing as nonowning_ptr, since it has
overhead, and Chromium uses T* to mean "non-owning pointer" (at least
in places we haven't switched over to scoped_ptr (a C++98 emulation of
unique_ptr: https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/scoped_ptr.h)).

Jeffrey

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

On Mon, Jul 8, 2013 at 12:02 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Mon, Jul 8, 2013 at 11:02 AM, Martinho Fernandes
> <martinho.fernandes@gmail.com> wrote:
>> On Mon, Jul 8, 2013 at 7:59 PM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>>>
>>>
>>>
>>> On 8 July 2013 20:56, Nevin Liber <nevin@eviloverlord.com> wrote:
>>>>
>>>> On 8 July 2013 12:51, Ville Voutilainen <ville.voutilainen@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> We have handle that completely transfers/holds ownership (unique_ptr), we
>>>>> have a handle
>>>>> that shares ownership (shared_ptr), but we have no handle that doesn't
>>>>> transfer/hold ownership
>>>>> at all. T* does all of that and none of that depending on how people use
>>>>> it, and fails to convey
>>>>> the semantics at a glance in a function signature.
>>>>
>>>>
>>>> Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial
>>>> to implement) or unique_ptr (required a language change to implement) and is
>>>> fairly simple to implement.  Where is the existing practice to standardize?
>>>
>>>
>>> Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>>>
>>
>> That looks like a weak_ptr.
>
> Ah, Chromium has a "WeakPtr" that serves the same purpose:
> https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/weak_ptr.h.
>
> It's very different from a std::weak_ptr in that the underlying object
> doesn't need to be refcounted, but it's very useful in its own right.
> It's definitely *not* the same thing as nonowning_ptr, since it has

> overhead, and Chromium uses T* to mean "non-owning pointer" (at least
> in places we haven't switched over to scoped_ptr (a C++98 emulation of
> unique_ptr: https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/scoped_ptr.h)).

Um, I mean that T* means "non-owning pointer", except in places where
it means "owning pointer" because we haven't yet switched everything
over to scoped_ptr.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--nextPart16374839.2c1rc6Ym9d
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On segunda-feira, 8 de julho de 2013 20.02.17, Martinho Fernandes wrote:
> >> Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial
> >> to implement) or unique_ptr (required a language change to implement) and
> >> is fairly simple to implement.  Where is the existing practice to
> >> standardize?>
> > Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>
> That looks like a weak_ptr.

QPointer is a weak pointer. The implementation in Qt 5 is actually using a
QWeakPointer. The big difference from QWeakPointer is that you *can* construct
a QPointer from a raw pointer, but you can't do that with QWeakPointer -- it
has to come from a QSharedPointer, since something must own at least one
reference.

You may be interested in these classes too:

 WTF::RefPtr -   intrusive pointer / internal reference counting
 WTF::PassRefPtr -  passing RefPtr
 WTF::OwnPtr -   no reference counting, like unique_ptr
 WTF::PassOwnPtr -  passing OwnPtr
https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PassOwnPtr.h and others

There doesn't seem to be a class for external reference counting.

Unfortunately, the documentation is quite lacking.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart16374839.2c1rc6Ym9d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBR2xdJM/XwBW70U1gRAg2wAJ0eWp0rLzTrXIlzLgbcG6BiO0HRtQCcD2cz
fyZmWejNiTnKsPzkyM/ZcVA=
=dnZQ
-----END PGP SIGNATURE-----

--nextPart16374839.2c1rc6Ym9d--


.

--047d7b6dcf5231f9e704e105a531
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 22:04, Jeffrey Yasskin <jyasskin@google.com> wrote:

>
> Um, I mean that T* means "non-owning pointer", except in places where
> it means "owning pointer" because we haven't yet switched everything
> over to scoped_ptr.
>
>
>
Well, in each and every project I have worked on, whenever any of
T* f(U*);
void f(T*);
T* f();
T* member;
appears, code reviewers start asking questions about ownership, without
exception.
It would actually save time and money to have a standardized vocabulary
type that
says "ownership is not transferred". The existing practice for these is to
consider whether
it's worth the trouble to add a custom non-transferring dumb pointer (which
has to be
separately taught since people won't recognize it from other projects), or
to just comment
the signatures and hope for the best, usually picking the latter, and then
debugging
like mad. I'd love to have both of Walter's proposals, and then just leave
intrusive pointers
and externally refcounted pointers outside the standard if need be. But
both the non-owning
and the cloning pointers often appear necessary, and seem like they could
be tools that
developers might happily adopt. I sure as hell would.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7b6dcf5231f9e704e105a531
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 22:04, Jeffrey Yasskin <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jyasskin@google.com" target=3D"_blank">jyasskin@google.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><br>
</div></div>Um, I mean that T* means &quot;non-owning pointer&quot;, except=
 in places where<br>
it means &quot;owning pointer&quot; because we haven&#39;t yet switched eve=
rything<br>
over to scoped_ptr.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote><d=
iv><br></div><div>Well, in each and every project I have worked on, wheneve=
r any of<br></div><div>T* f(U*);<br></div><div>void f(T*);<br></div><div>T*=
 f();<br>
</div><div>T* member;<br></div><div>appears, code reviewers start asking qu=
estions about ownership, without exception.<br></div><div>It would actually=
 save time and money to have a standardized vocabulary type that<br>says &q=
uot;ownership is not transferred&quot;. The existing practice for these is =
to consider whether<br>
it&#39;s worth the trouble to add a custom non-transferring dumb pointer (w=
hich has to be<br>separately taught since people won&#39;t recognize it fro=
m other projects), or to just comment<br>the signatures and hope for the be=
st, usually picking the latter, and then debugging<br>
</div><div>like mad. I&#39;d love to have both of Walter&#39;s proposals, a=
nd then just leave intrusive pointers<br>and externally refcounted pointers=
 outside the standard if need be. But both the non-owning<br></div><div>
and the cloning pointers often appear necessary, and seem like they could b=
e tools that<br></div><div>developers might happily adopt. I sure as hell w=
ould.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6dcf5231f9e704e105a531--

.

On Mon, Jul 8, 2013 at 1:11 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>
>
> On 8 July 2013 22:04, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>>
>> Um, I mean that T* means "non-owning pointer", except in places where
>> it means "owning pointer" because we haven't yet switched everything
>> over to scoped_ptr.
>>
>>
>
> Well, in each and every project I have worked on, whenever any of
> T* f(U*);
> void f(T*);
> T* f();
> T* member;
> appears, code reviewers start asking questions about ownership, without
> exception.

I'd like to double-check that these projects were started after C++11
was released and that they use std::unique_ptr, std::shared_ptr, or
some other smart point to hold every owned pointer?

If your experience (like most of ours) is still mostly on transitional
projects, I do agree that the exempt_ptr would save some communication
time during the transition, but it won't speed up the transition to
unique_ptr, and I expect that once we're done with the transition,
exempt_ptr will just be a verbose wart.

Jeffrey

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--14dae9c0935e1045b304e105e058
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 15:11, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
>
>
> On 8 July 2013 22:04, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
>>
>> Um, I mean that T* means "non-owning pointer", except in places where
>> it means "owning pointer" because we haven't yet switched everything
>> over to scoped_ptr.
>>
>>
>>
> Well, in each and every project I have worked on, whenever any of
> T* f(U*);
> void f(T*);
> T* f();
> T* member;
> appears, code reviewers start asking questions about ownership, without
> exception.
> It would actually save time and money to have a standardized vocabulary
> type that
> says "ownership is not transferred". The existing practice for these is to
> consider whether
> it's worth the trouble to add a custom non-transferring dumb pointer
> (which has to be
> separately taught since people won't recognize it from other projects), or
> to just comment
> the signatures and hope for the best, usually picking the latter, and then
> debugging
> like mad.
>

So, why haven't you introduced it to your code base?  I don't mean that
facetiously.  I would not want to adopt something like this into the
standard without significant user experience, because in some sense
developers will assume we are dictating this as a best practice for 2017
and beyond.

In my code bases, raw pointers are rare and usually used for calling C
APIs, for which all this becomes is noise.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--14dae9c0935e1045b304e105e058
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 July 2013 15:11, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 8 July 2013 22:04, Jeffrey Yasskin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jyasskin@google.com" target=3D"_blank">jyass=
kin@google.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div><br>
</div></div>Um, I mean that T* means &quot;non-owning pointer&quot;, except=
 in places where<br>
it means &quot;owning pointer&quot; because we haven&#39;t yet switched eve=
rything<br>
over to scoped_ptr.<br>
<div><div><br><br></div></div></blockquote><div><br></div></div><div>Well, =
in each and every project I have worked on, whenever any of<br></div><div>T=
* f(U*);<br></div><div>void f(T*);<br></div><div>T* f();<br>
</div><div>T* member;<br></div><div>appears, code reviewers start asking qu=
estions about ownership, without exception.<br></div><div>It would actually=
 save time and money to have a standardized vocabulary type that<br>says &q=
uot;ownership is not transferred&quot;. The existing practice for these is =
to consider whether<br>


it&#39;s worth the trouble to add a custom non-transferring dumb pointer (w=
hich has to be<br>separately taught since people won&#39;t recognize it fro=
m other projects), or to just comment<br>the signatures and hope for the be=
st, usually picking the latter, and then debugging<br>


</div><div>like mad.</div></div></div></div></blockquote><div><br>So, why h=
aven&#39;t you introduced it to your code base?=A0 I don&#39;t mean that fa=
cetiously.=A0 I would not want to adopt something like this into the standa=
rd without significant user experience, because in some sense developers wi=
ll assume we are dictating this as a best practice for 2017 and beyond.<br>

<br>In my code bases, raw pointers are rare and usually used for calling C =
APIs, for which all this becomes is noise.<br clear=3D"all"></div></div>-- =
<br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@ev=
iloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 6=
91-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9c0935e1045b304e105e058--

.

------=_Part_6763_7951439.1373315852548
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. j=FAlius 8., h=E9tf=F5 22:26:56 UTC+2 id=F5pontban Nevin ":-)" Liber =
a=20
k=F6vetkez=F5t =EDrta:
>
>
> In my code bases, raw pointers are rare and usually used for calling C=20
> APIs, for which all this becomes is noise.
> --=20
>

Just for curiosity, do you never need reseat-able references, or do you=20
simply use std::reference_wrapper?

Regards, Robert

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



------=_Part_6763_7951439.1373315852548
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. j=FAlius 8., h=E9tf=F5 22:26:56 UTC+2 id=F5pontban Nevin ":-)=
" Liber a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><br><div class=3D"gmail_quote"><div>In my code bases, raw pointers are ra=
re and usually used for calling C APIs, for which all this becomes is noise=
..<br clear=3D"all"></div></div>-- <br></blockquote><div><br>Just for curios=
ity, do you never need reseat-able references, or do you simply use std::re=
ference_wrapper?<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6763_7951439.1373315852548--

.

--047d7bb03d36844f2504e106136a
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 23:26, Nevin Liber <nevin@eviloverlord.com> wrote:

> says "ownership is not transferred". The existing practice for these is to
> consider whether
>
>> it's worth the trouble to add a custom non-transferring dumb pointer
>> (which has to be
>> separately taught since people won't recognize it from other projects),
>> or to just comment
>> the signatures and hope for the best, usually picking the latter, and
>> then debugging
>> like mad.
>>
>
> So, why haven't you introduced it to your code base?  I don't mean that
> facetiously.  I would not want to adopt something like this
>

I have, a couple of times. In some cases it was

template <class T> struct ptr_wrap
{
    T* ptr_;
};

and there have been cases where for different reasons it was

struct TNodeHandle
{
    void* iNodeData;
};

The user experience I have for these is that they take care of the deletion
issues, but don't provide
a convenient user interface for using them like pointers. For the latter,
that wasn't even a design
target, though, since it's opaque. The latter actually provides another
reason to avoid raw pointers;
any T******** converts to void*, even when T is itself void. It has been my
user experience that
avoiding raw pointers and using non-owning wrappers protects from such
conversions.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bb03d36844f2504e106136a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 23:26, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">says &quot;ownership is not transferred&quot=
;. The existing practice for these is to consider whether<br><div class=3D"=
gmail_quote">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>


it&#39;s worth the trouble to add a custom non-transferring dumb pointer (w=
hich has to be<br>separately taught since people won&#39;t recognize it fro=
m other projects), or to just comment<br>the signatures and hope for the be=
st, usually picking the latter, and then debugging<br>



</div><div>like mad.</div></div></div></div></blockquote></div><div><br>So,=
 why haven&#39;t you introduced it to your code base?=A0 I don&#39;t mean t=
hat facetiously.=A0 I would not want to adopt something like this </div></d=
iv>
</blockquote><div><br></div><div>I have, a couple of times. In some cases i=
t was<br><br></div><div>template &lt;class T&gt; struct ptr_wrap<br>{<br></=
div><div>=A0=A0=A0 T* ptr_;<br></div><div>}; <br><br></div><div>and there h=
ave been cases where for different reasons it was<br>
<br></div><div>struct TNodeHandle<br>{<br></div><div>=A0=A0=A0 void* iNodeD=
ata;<br></div><div>};<br><br></div><div>The user experience I have for thes=
e is that they take care of the deletion issues, but don&#39;t provide<br><=
/div>
<div>a convenient user interface for using them like pointers. For the latt=
er, that wasn&#39;t even a design<br>target, though, since it&#39;s opaque.=
 The latter actually provides another reason to avoid raw pointers;<br>
</div><div>any T******** converts to void*, even when T is itself void. It =
has been my user experience that<br>avoiding raw pointers and using non-own=
ing wrappers protects from such conversions.<br></div><br></div></div></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bb03d36844f2504e106136a--

.

--20cf306844d53a713a04e10632e3
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 23:22, Jeffrey Yasskin <jyasskin@google.com> wrote:

> > Well, in each and every project I have worked on, whenever any of
> > T* f(U*);
> > void f(T*);
> > T* f();
> > T* member;
> > appears, code reviewers start asking questions about ownership, without
> > exception.
>
> I'd like to double-check that these projects were started after C++11
> was released and that they use std::unique_ptr, std::shared_ptr, or
> some other smart point to hold every owned pointer?
>

Most of them were started way before c++11, and some used auto_ptr and
boost::shared_ptr
for each and every owned pointer. Some of them have used custom smart
pointers for
every owned pointer, and for even non-owned pointers. Some of them have
used
const auto_ptr<T>& for cases where ownership is not transferred. The
experience thus far
has been, to me, that the wrapping of non-owned pointers saved a lot of
time both
avoiding clients erroneously attempting to delete, and also with the other
point that I made in my
reply to Nevin, avoiding conversions to void*. The case of const
auto_ptr<T>& was
that it didn't achieve what it attempted to, which is clarity and
readability of interfaces,
and whenever that was passed into classes, those classes had to get() the
pointer
and store it into a non-owning handle or raw pointer anyway, since there
was no
usable non-owning dumb pointer available. I don't see c++11 changing that.



> If your experience (like most of ours) is still mostly on transitional
> projects, I do agree that the exempt_ptr would save some communication
> time during the transition, but it won't speed up the transition to
> unique_ptr, and I expect that once we're done with the transition,
> exempt_ptr will just be a verbose wart.
>
>
>
The thing is that I'm talking about cases where unique_ptr will not be the
final type to be used.
I have done large conversions from raw pointers to shared pointers and
auto_ptr. Going from those
auto_ptrs to unique_ptr is a piece of cake. What to do with the leftover
cases where ownership
isn't transferred is the harder part. Trying to treat raw T* as that
non-transferring vocabulary
type has proven to be hard.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--20cf306844d53a713a04e10632e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 23:22, Jeffrey Yasskin <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jyasskin@google.com" target=3D"_blank">jyasskin@google.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">&gt; Well, in each and eve=
ry project I have worked on, whenever any of<br>
&gt; T* f(U*);<br>
&gt; void f(T*);<br>
&gt; T* f();<br>
&gt; T* member;<br>
&gt; appears, code reviewers start asking questions about ownership, withou=
t<br>
&gt; exception.<br>
<br>
</div>I&#39;d like to double-check that these projects were started after C=
++11<br>
was released and that they use std::unique_ptr, std::shared_ptr, or<br>
some other smart point to hold every owned pointer?<br></blockquote><div><b=
r></div><div>Most of them were started way before c++11, and some used auto=
_ptr and boost::shared_ptr<br></div><div>for each and every owned pointer. =
Some of them have used custom smart pointers for <br>
every owned pointer, and for even non-owned pointers. Some of them have use=
d <br>const auto_ptr&lt;T&gt;&amp; for cases where ownership is not transfe=
rred. The experience thus far <br>has been, to me, that the wrapping of non=
-owned pointers saved a lot of time both <br>
avoiding clients erroneously attempting to delete, and also with the other =
point that I made in my<br>reply to Nevin, avoiding conversions to void*. T=
he case of const auto_ptr&lt;T&gt;&amp; was<br>that it didn&#39;t achieve w=
hat it attempted to, which is clarity and readability of interfaces,<br>
and whenever that was passed into classes, those classes had to get() the p=
ointer<br>and store it into a non-owning handle or raw pointer anyway, sinc=
e there was no<br>usable non-owning dumb pointer available. I don&#39;t see=
 c++11 changing that.<br>
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<br>
If your experience (like most of ours) is still mostly on transitional<br>
projects, I do agree that the exempt_ptr would save some communication<br>
time during the transition, but it won&#39;t speed up the transition to<br>
unique_ptr, and I expect that once we&#39;re done with the transition,<br>
exempt_ptr will just be a verbose wart.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>The thing is that I&#39;m talking about cases wh=
ere unique_ptr will not be the final type to be used.<br></div><div>I have =
done large conversions from raw pointers to shared pointers and auto_ptr. G=
oing from those<br>
auto_ptrs to unique_ptr is a piece of cake. What to do with the leftover ca=
ses where ownership<br>isn&#39;t transferred is the harder part. Trying to =
treat raw T* as that non-transferring vocabulary<br>type has proven to be h=
ard.<br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf306844d53a713a04e10632e3--

.

--001a11c3e0e46a396f04e1063760
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 8 July 2013 15:37, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:

>
>
> 2013. j=FAlius 8., h=E9tf=F5 22:26:56 UTC+2 id=F5pontban Nevin ":-)" Libe=
r a
> k=F6vetkez=F5t =EDrta:
>
>>
>> In my code bases, raw pointers are rare and usually used for calling C
>> APIs, for which all this becomes is noise.
>> --
>>
>
> Just for curiosity, do you never need reseat-able references, or do you
> simply use std::reference_wrapper?
>

Within a function call, I rarely need reseatable references. Having to
reseat the reference is an indicator that the function is doing too much
work.

As a member variable, I'll use raw pointers over references so as not to
break assignability.  reference_wrapper is certainly another way to
indicate this, but I find it noisy unless you need the reference syntax in
another context.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



--001a11c3e0e46a396f04e1063760
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 8 July 2013 15:37, R=F3bert D=E1vid <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>&gt;</span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br>2013. j=FAlius 8., h=E9tf=F5 22:26:56 UTC+2 id=F5pontban Nevin &quo=
t;:-)&quot; Liber a k=F6vetkez=F5t =EDrta:<div class=3D"im"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">

<br><div class=3D"gmail_quote"><div>In my code bases, raw pointers are rare=
 and usually used for calling C APIs, for which all this becomes is noise.<=
br clear=3D"all"></div></div>-- <br></blockquote></div><div><br>Just for cu=
riosity, do you never need reseat-able references, or do you simply use std=
::reference_wrapper?<br>

</div></blockquote><div><br>Within a function call, I rarely need reseatabl=
e references. Having to reseat the reference is an indicator that the funct=
ion is doing too much work.<br><br>As a member variable, I&#39;ll use raw p=
ointers over references so as not to break assignability.=A0 reference_wrap=
per is certainly another way to indicate this, but I find it noisy unless y=
ou need the reference syntax in another context.<br clear=3D"all">

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3e0e46a396f04e1063760--

.

On Mon, Jul 8, 2013 at 1:50 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>
>
> On 8 July 2013 23:22, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>> > Well, in each and every project I have worked on, whenever any of
>> > T* f(U*);
>> > void f(T*);
>> > T* f();
>> > T* member;
>> > appears, code reviewers start asking questions about ownership, without
>> > exception.
>>
>> I'd like to double-check that these projects were started after C++11
>> was released and that they use std::unique_ptr, std::shared_ptr, or
>> some other smart point to hold every owned pointer?
>
>
> Most of them were started way before c++11, and some used auto_ptr and
> boost::shared_ptr
> for each and every owned pointer. Some of them have used custom smart
> pointers for
> every owned pointer, and for even non-owned pointers. Some of them have used
> const auto_ptr<T>& for cases where ownership is not transferred. The
> experience thus far
> has been, to me, that the wrapping of non-owned pointers saved a lot of time
> both
> avoiding clients erroneously attempting to delete, and also with the other
> point that I made in my
> reply to Nevin, avoiding conversions to void*. The case of const
> auto_ptr<T>& was
> that it didn't achieve what it attempted to, which is clarity and
> readability of interfaces,
> and whenever that was passed into classes, those classes had to get() the
> pointer
> and store it into a non-owning handle or raw pointer anyway, since there was
> no
> usable non-owning dumb pointer available. I don't see c++11 changing that.

Ok, that sounds like solid and applicable experience. Thanks.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--089e0111bcfa54fdb804e106a037
Content-Type: text/plain; charset=ISO-8859-1

I just wanted to add some data: I have the same kind of experience than
Ville.
First thing to note is that boost already provided the smart pointers but
unique_ptr, as already pointed, so the previous codebases are still
relevant if upgraded to use current tools.
However, all projects I began with C++11 features enabled have this kind of
mechanism:

class A {};

class K
{
    std::map< Id<A>, std::unique_ptr<A> > m_objects;     // own A objects
    std::vector< A* > m_object_list;                                  //
refer to owned A objects in a specific order that can change often
};

// OR

class ObjectRegistry // references a specific set of A objects
{
    std::map< Id<A>, A* > m_index;
public:

    void add( A& a ); // we want a valid A instance but we don't want to
keep ownership
    void remove( const Id<A>& id ); // just remove the reference
}; // this might be associated to a custom smart pointer which
automatically call the add() and remove() functions.

Assume that ObjectRegistry is used in contexts where the add/remove
operations are called at high frequency
Often, in my experience, this kind of system is used over a pool system,
where the pool own the data and
set it up in a way that helps working with it (like in arrays for
data-centric approaches), then references
to that data are pushed into other systems to use it, but they never own
the data.

I have basically two kind of setup where I see this:
 - in an explicitely concurrent system, then shared_ptr/weak_ptr is the
right tool there;
 - in non-concurrent system, shared_ptr/weak_ptr could be used but adds a
cost required by concurrent contexts but not by non-concurrent ones, which
can hit hard in some contexts;
So currently I prefer to use raw pointers for non-owning resettable
references when in non-concurrent systems.
Indeed it often causes confusion with coworkers: banning totally using
new/delete and saying that if there is a naked pointer it's a non-owning
reference helps a lot
but it apparently still invoke doubts in minds used to see pointers as a
too-flexible tool.

So to me, both clarification of intent and using the right tool in high
performance context are reasons why I'd like to see how such a proposal
would go.

By the way, what were the reactions on the official mailing list (which is
not readable publicly)  to N3514 and N3339?

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--089e0111bcfa54fdb804e106a037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just wanted to add some data: I have the same kind of ex=
perience than Ville.<div>First thing to note is that boost already provided=
 the smart pointers but unique_ptr, as already pointed, so the previous cod=
ebases are still relevant if upgraded to use current tools.</div>
<div>However, all projects I began with C++11 features enabled have this ki=
nd of mechanism:</div><div><br></div><div>class A {};</div><div><br></div><=
div>class K</div><div>{</div><div>=A0 =A0 std::map&lt; Id&lt;A&gt;, std::un=
ique_ptr&lt;A&gt; &gt; m_objects; =A0 =A0 // own A objects</div>
<div>=A0 =A0 std::vector&lt; A* &gt; m_object_list; =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// refer to owned A objects in =
a specific order that can change often</div><div>};</div><div><br></div><di=
v>// OR</div><div><br></div><div>class ObjectRegistry // references a speci=
fic set of A objects</div>
<div>{</div><div>=A0 =A0 std::map&lt; Id&lt;A&gt;, A* &gt; m_index;</div><d=
iv>public:</div><div><br></div><div>=A0 =A0 void add( A&amp; a ); // we wan=
t a valid A instance but we don&#39;t want to keep ownership</div><div>=A0 =
=A0 void remove( const Id&lt;A&gt;&amp; id ); // just remove the reference<=
/div>
<div>}; // this might be associated to a custom smart pointer which automat=
ically call the add() and remove() functions.</div><div><br></div><div>Assu=
me that ObjectRegistry is used in contexts where the add/remove operations =
are called at high frequency</div>
<div>Often, in my experience, this kind of system is used over a pool syste=
m, where the pool own the data and</div><div>set it up in a way that helps =
working with it (like in arrays for data-centric approaches), then referenc=
es</div>
<div>to that data are pushed into other systems to use it, but they never o=
wn the data.</div><div><br></div><div>I have basically two kind of setup wh=
ere I see this:</div><div>=A0- in an explicitely concurrent system, then sh=
ared_ptr/weak_ptr is the right tool there;</div>
<div>=A0- in non-concurrent system, shared_ptr/weak_ptr could be used but a=
dds a cost required by concurrent contexts but not by non-concurrent ones, =
which can hit hard in some contexts;</div><div>So currently I prefer to use=
 raw pointers for non-owning resettable references when in non-concurrent s=
ystems.</div>
<div>Indeed it often causes confusion with coworkers: banning totally using=
 new/delete and saying that if there is a naked pointer it&#39;s a non-owni=
ng reference helps a lot</div><div>but it apparently still invoke doubts in=
 minds used to see pointers as a too-flexible tool.</div>
<div><br></div><div>So to me, both clarification of intent and using the ri=
ght tool in high performance context are reasons why I&#39;d like to see ho=
w such a proposal would go.</div><div><br></div><div>By the way, what were =
the reactions on the official mailing list (which is not readable publicly)=
 =A0to N3514 and N3339?</div>
<div><br></div><div>Joel Lamotte</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0111bcfa54fdb804e106a037--

.

--047d7b6da6160fb03e04e106cd11
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 July 2013 00:21, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:

> By the way, what were the reactions on the official mailing list (which i=
s
> not readable publicly)  to N3514 and N3339?
>
>
>
I can't find any in-meeting discussions on either of them. Walter wasn't
present in either Portland or Bristol.
These papers need a champion...

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



--047d7b6da6160fb03e04e106cd11
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 July 2013 00:21, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">By the way, what were the r=
eactions on the official mailing list (which is not readable publicly) =A0t=
o N3514 and N3339?
<div><br><br></div></div></blockquote><div><br></div><div>I can&#39;t find =
any in-meeting discussions on either of them. Walter wasn&#39;t present in =
either Portland or Bristol.<br></div><div>These papers need a champion... <=
br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6da6160fb03e04e106cd11--

.

--20cf3074d4e0b9b12204e106f075
Content-Type: text/plain; charset=ISO-8859-1

On 8 July 2013 16:33, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
> I can't find any in-meeting discussions on either of them. Walter wasn't
> present in either Portland or Bristol.
>

I thought Walter was in Portland.

I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one
of the very last things discussed).  The sentiment in the room was that it
should be investigated, along with other slightly different smart pointers
(such as dumb but moveable).

I don't think clone_ptr has been discussed since Kona.


> These papers need a champion...
>

I assume Walter will be at the Chicago meeting, given he is relatively
local.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--20cf3074d4e0b9b12204e106f075
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 July 2013 16:33, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra">I can&#39;t find any in-mee=
ting discussions on either of them. Walter wasn&#39;t present in either Por=
tland or Bristol.<br></div></div></blockquote><div><br>I thought Walter was=
 in Portland. <br>

</div><div><br>I know that dumb_ptr was briefly discussed in Bristol in LEW=
G (it was one of the very last things discussed).=A0 The sentiment in the r=
oom was that it should be investigated, along with other slightly different=
 smart pointers (such as dumb but moveable).<br>

<br>I don&#39;t think clone_ptr has been discussed since Kona.<br>=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">

<div>These papers need a champion...<br></div></div></div></div></blockquot=
e><div><br>I assume Walter will be at the Chicago meeting, given he is rela=
tively local. <br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf3074d4e0b9b12204e106f075--

.

--047d7bb03d36d76a0a04e106fcbc
Content-Type: text/plain; charset=ISO-8859-1

On 9 July 2013 00:43, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 8 July 2013 16:33, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>> I can't find any in-meeting discussions on either of them. Walter wasn't
>> present in either Portland or Bristol.
>>
>
> I thought Walter was in Portland.
>

Me too, first, but the minutes etc. show him absent.


>
> I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one
> of the very last things discussed).  The sentiment in the room was that it
> should be investigated, along with other slightly different smart pointers
> (such as dumb but moveable).
>
> I don't think clone_ptr has been discussed since Kona.
>
>
>> These papers need a champion...
>>
>
> I assume Walter will be at the Chicago meeting, given he is relatively
> local.
>

Good point. Then again, we'll be in c++14 NB comments up to our eyeballs in
Chicago, so that may not be sufficient.
I suppose interested parties can work with Walter to get these things
forward.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bb03d36d76a0a04e106fcbc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 July 2013 00:43, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 8 July 2013 16:33, Vill=
e Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gma=
il.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:=
<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra">I can&#39;t find any in-mee=
ting discussions on either of them. Walter wasn&#39;t present in either Por=
tland or Bristol.<br></div></div></blockquote></div><div><br>I thought Walt=
er was in Portland. <br>
</div></div></blockquote><div><br></div><div>Me too, first, but the minutes=
 etc. show him absent.<br>=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D"gmail_quote">
<div>

</div><div><br>I know that dumb_ptr was briefly discussed in Bristol in LEW=
G (it was one of the very last things discussed).=A0 The sentiment in the r=
oom was that it should be investigated, along with other slightly different=
 smart pointers (such as dumb but moveable).<br>


<br>I don&#39;t think clone_ptr has been discussed since Kona.<br>=A0</div>=
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra">
<div class=3D"gmail_quote">

<div>These papers need a champion...<br></div></div></div></div></blockquot=
e></div><div><br>I assume Walter will be at the Chicago meeting, given he i=
s relatively local. <br></div></div></blockquote><div><br></div><div>Good p=
oint. Then again, we&#39;ll be in c++14 NB comments up to our eyeballs in C=
hicago, so that may not be sufficient.<br>
</div><div>I suppose interested parties can work with Walter to get these t=
hings forward.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bb03d36d76a0a04e106fcbc--

.

--001a11c2ed4ae5696504e107006a
Content-Type: text/plain; charset=ISO-8859-1

On 9 July 2013 00:47, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
>
>
> On 9 July 2013 00:43, Nevin Liber <nevin@eviloverlord.com> wrote:
>
>> On 8 July 2013 16:33, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>>
>>>
>>> I can't find any in-meeting discussions on either of them. Walter wasn't
>>> present in either Portland or Bristol.
>>>
>>
>> I thought Walter was in Portland.
>>
>
> Me too, first, but the minutes etc. show him absent.
>
>
Scratch that. He was no longer a Fermilab delegate. He was indeed there.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--001a11c2ed4ae5696504e107006a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 July 2013 00:47, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 9 July 2013 00:=
43, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 8 July 2013 16:33, Ville Voutilainen=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" targe=
t=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br>

</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra">I can&#39;t find any in-mee=
ting discussions on either of them. Walter wasn&#39;t present in either Por=
tland or Bristol.<br></div></div></blockquote></div><div><br>I thought Walt=
er was in Portland. <br>

</div></div></blockquote><div><br></div></div><div>Me too, first, but the m=
inutes etc. show him absent.<br><br></div></div></div></div></blockquote><d=
iv><br></div><div>Scratch that. He was no longer a Fermilab delegate. He wa=
s indeed there.=A0 <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2ed4ae5696504e107006a--

.

------=_Part_1271_10024017.1373364898616
Content-Type: text/plain; charset=ISO-8859-1



On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:
>
>
> I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one
> of the very last things discussed).  The sentiment in the room was that it
> should be investigated, along with other slightly different smart pointers
> (such as dumb but moveable).
>

More accurately (since dumb_ptr is also movable) the case I raised was a
non-owning pointer that is dumb and **guaranteed to be null when
moved-from**.  That is useful as a data member (rather than in function
signatures) because it makes it easier to follow the Rule of Zero and is a
useful building block for smarter types.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_1271_10024017.1373364898616
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><br><div class=3D"gmail_quote"=
><div>I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was=
 one of the very last things discussed).&nbsp; The sentiment in the room wa=
s that it should be investigated, along with other slightly different smart=
 pointers (such as dumb but moveable).<br></div></div></blockquote><div><br=
>More accurately (since dumb_ptr is also movable) the case I raised was a n=
on-owning pointer that is dumb and **guaranteed to be null when moved-from*=
*.&nbsp; That is useful as a data member (rather than in function signature=
s) because it makes it easier to follow the Rule of Zero and is a useful bu=
ilding block for smarter types.<br></div><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1271_10024017.1373364898616--

.

--047d7bd768564a6e3b04e115f7fd
Content-Type: text/plain; charset=ISO-8859-1

On 9 July 2013 05:14, Jonathan Wakely <cxx@kayari.org> wrote:

>
>
> On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:
>>
>>
>> I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one
>> of the very last things discussed).  The sentiment in the room was that it
>> should be investigated, along with other slightly different smart pointers
>> (such as dumb but moveable).
>>
>
> More accurately (since dumb_ptr is also movable) the case I raised was a
> non-owning pointer that is dumb and **guaranteed to be null when
> moved-from**.  That is useful as a data member (rather than in function
> signatures) because it makes it easier to follow the Rule of Zero and is a
> useful building block for smarter types.
>

Instead of that being a smart pointer, I'd rather have a more general
template that can be applied to any scalar type, such as (warning: this is
just proof of concept code):

template<typename T, T v = T{}>
struct moveit
{
    using value_type = T;
    static constexpr const value_type moved_from_value = v;

    moveit(moveit const&) = default;
    moveit& operator=(moveit const& that) = default;
    ~moveit() = default;

    moveit(moveit&& that) : value(that.value) { that.value = v; }
    moveit& operator=(moveit&& that) { value = that.value; that.value = v;
return *this; }

    moveit(value_type t = v) : value(t) {}

    value_type& get() noexcept { return value; }
    value_type const& get() const noexcept { return value; }
    operator value_type&() noexcept { return value; }
    operator value_type const&() const noexcept { return value; }

private:
    value_type value;
};

template<typename T, T* v>
struct moveit<T*, v>
{
    using value_type = T*;
    static constexpr const value_type moved_from_value = v;

    moveit(moveit const&) = default;
    moveit& operator=(moveit const& that) = default;
    ~moveit() = default;

    moveit(moveit&& that) : value(that.value) { that.value = v; }
    moveit& operator=(moveit&& that) { value = that.value; that.value = v;
return *this; }

    moveit(value_type t = v) : value(t) {}

    value_type& get() noexcept { return value; }
    value_type const& get() const noexcept { return value; }
    operator value_type&() noexcept { return value; }
    operator value_type const&() const noexcept { return value; }

    T& operator*() const noexcept { return *value; }
    value_type operator->() const noexcept { return value; }

private:
    value_type value;
};

I'd also rather not combine that with blocking delete, as those are
separate concerns.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bd768564a6e3b04e115f7fd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 July 2013 05:14, Jonathan Wakely <span dir=3D"ltr">&lt;<a href=3D"mail=
to:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span> wrote:<b=
r><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br><br>On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin =
&quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><di=
v class=3D"gmail_quote">

<div>I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was =
one of the very last things discussed).=A0 The sentiment in the room was th=
at it should be investigated, along with other slightly different smart poi=
nters (such as dumb but moveable).<br>

</div></div></blockquote></div><div><br>More accurately (since dumb_ptr is =
also movable) the case I raised was a non-owning pointer that is dumb and *=
*guaranteed to be null when moved-from**.=A0 That is useful as a data membe=
r (rather than in function signatures) because it makes it easier to follow=
 the Rule of Zero and is a useful building block for smarter types.<br clea=
r=3D"all">

</div></blockquote><div><br>Instead of that being a smart pointer, I&#39;d =
rather have a more general template that can be applied to any scalar type,=
 such as (warning: this is just proof of concept code):<br></div></div>

<br><font size=3D"1"><span style=3D"font-family:courier new,monospace">temp=
late&lt;typename T, T v =3D T{}&gt;<br>struct moveit<br>{<br>=A0=A0=A0 usin=
g value_type =3D T;<br>=A0=A0=A0 static constexpr const value_type moved_fr=
om_value =3D v;<br>

<br>=A0=A0=A0 moveit(moveit const&amp;) =3D default;<br>=A0=A0=A0 moveit&am=
p; operator=3D(moveit const&amp; that) =3D default;<br>=A0=A0=A0 ~moveit() =
=3D default;<br><br>=A0=A0=A0 moveit(moveit&amp;&amp; that) : value(that.va=
lue) { that.value =3D v; }<br>

=A0=A0=A0 moveit&amp; operator=3D(moveit&amp;&amp; that) { value =3D that.v=
alue; that.value =3D v; return *this; }<br><br>=A0=A0=A0 moveit(value_type =
t =3D v) : value(t) {}<br><br>=A0=A0=A0 value_type&amp; get() noexcept { re=
turn value; }<br>=A0=A0=A0 value_type const&amp; get() const noexcept { ret=
urn value; }<br>

=A0=A0=A0 operator value_type&amp;() noexcept { return value; }<br>=A0=A0=
=A0 operator value_type const&amp;() const noexcept { return value; }<br><b=
r>private:<br>=A0=A0=A0 value_type value;<br>};<br><br>template&lt;typename=
 T, T* v&gt;<br>

struct moveit&lt;T*, v&gt;<br>{<br>=A0=A0=A0 using value_type =3D T*;<br>=
=A0=A0=A0 static constexpr const value_type moved_from_value =3D v;<br><br>=
=A0=A0=A0 moveit(moveit const&amp;) =3D default;<br>=A0=A0=A0 moveit&amp; o=
perator=3D(moveit const&amp; that) =3D default;<br>

=A0=A0=A0 ~moveit() =3D default;<br><br>=A0=A0=A0 moveit(moveit&amp;&amp; t=
hat) : value(that.value) { that.value =3D v; }<br>=A0=A0=A0 moveit&amp; ope=
rator=3D(moveit&amp;&amp; that) { value =3D that.value; that.value =3D v; r=
eturn *this; }<br><br>=A0=A0=A0 moveit(value_type t =3D v) : value(t) {}<br=
>

<br>=A0=A0=A0 value_type&amp; get() noexcept { return value; }<br>=A0=A0=A0=
 value_type const&amp; get() const noexcept { return value; }<br>=A0=A0=A0 =
operator value_type&amp;() noexcept { return value; }<br>=A0=A0=A0 operator=
 value_type const&amp;() const noexcept { return value; }<br>

<br>=A0=A0=A0 T&amp; operator*() const noexcept { return *value; }<br>=A0=
=A0=A0 value_type operator-&gt;() const noexcept { return value; }<br><br>p=
rivate:<br>=A0=A0=A0 value_type value;<br>};<br></span></font><br>I&#39;d a=
lso rather not combine that with blocking delete, as those are separate con=
cerns.<br>

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bd768564a6e3b04e115f7fd--

.

--047d7bea3fce241ce704e1160201
Content-Type: text/plain; charset=ISO-8859-1

On 9 July 2013 18:38, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 9 July 2013 05:14, Jonathan Wakely <cxx@kayari.org> wrote:
>
>>
>>
>> On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:
>>>
>>>
>>> I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was
>>> one of the very last things discussed).  The sentiment in the room was that
>>> it should be investigated, along with other slightly different smart
>>> pointers (such as dumb but moveable).
>>>
>>
>> More accurately (since dumb_ptr is also movable) the case I raised was a
>> non-owning pointer that is dumb and **guaranteed to be null when
>> moved-from**.  That is useful as a data member (rather than in function
>> signatures) because it makes it easier to follow the Rule of Zero and is a
>> useful building block for smarter types.
>>
>
> Instead of that being a smart pointer, I'd rather have a more general
> template that can be applied to any scalar type, such as (warning: this is
> just proof of concept code):
>
>
At any rate, I'd prefer dumb_ptr not zeroing the original when moved from.
A zeroing-when-moved-from wrapper
seems like a completely different type to me, and I'd prefer it being so. I
don't believe we should provide that
zeroing in dumb_ptr.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7bea3fce241ce704e1160201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 July 2013 18:38, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 9 July 2013 05:14, Jona=
than Wakely <span dir=3D"ltr">&lt;<a href=3D"mailto:cxx@kayari.org" target=
=3D"_blank">cxx@kayari.org</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<div><br><br>On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin &quot;:-)&quo=
t; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class=3D"gm=
ail_quote">


<div>I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was =
one of the very last things discussed).=A0 The sentiment in the room was th=
at it should be investigated, along with other slightly different smart poi=
nters (such as dumb but moveable).<br>


</div></div></blockquote></div><div><br>More accurately (since dumb_ptr is =
also movable) the case I raised was a non-owning pointer that is dumb and *=
*guaranteed to be null when moved-from**.=A0 That is useful as a data membe=
r (rather than in function signatures) because it makes it easier to follow=
 the Rule of Zero and is a useful building block for smarter types.<br clea=
r=3D"all">


</div></blockquote></div><div><br>Instead of that being a smart pointer, I&=
#39;d rather have a more general template that can be applied to any scalar=
 type, such as (warning: this is just proof of concept code):<br></div>
</div>

<br></blockquote><div><br></div><div>At any rate, I&#39;d prefer dumb_ptr n=
ot zeroing the original when moved from. A zeroing-when-moved-from wrapper<=
br>seems like a completely different type to me, and I&#39;d prefer it bein=
g so. I don&#39;t believe we should provide that<br>
zeroing in dumb_ptr.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea3fce241ce704e1160201--

.

------=_Part_9_12508181.1373459282816
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, July 9, 2013 4:38:46 PM UTC+1, Nevin ":-)" Liber wrote:
>
> More accurately (since dumb_ptr is also movable) the case I raised was a
> non-owning pointer that is dumb and **guaranteed to be null when
> moved-from**.  That is useful as a data member (rather than in function
> signatures) because it makes it easier to follow the Rule of Zero and is a
> useful building block for smarter types.
>
> Instead of that being a smart pointer, I'd rather have a more general
> template that can be applied to any scalar type,
>

I do have a more general class template, but it sets moved-from values to
their value-initialized state (so supports anything that is
DefaultConstructible.) It hadn't occurred to me to use a non-type template
parameter as the moved-from value, thanks.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_9_12508181.1373459282816
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, July 9, 2013 4:38:46 PM UTC+1, Nevin ":-)" Liber wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div>More accurately (since du=
mb_ptr is also movable) the case I raised was a non-owning pointer that is =
dumb and **guaranteed to be null when moved-from**.&nbsp; That is useful as=
 a data member (rather than in function signatures) because it makes it eas=
ier to follow the Rule of Zero and is a useful building block for smarter t=
ypes.<br clear=3D"all">

</div><div class=3D"gmail_quote"><div><br>Instead of that being a smart poi=
nter, I'd rather have a more general template that can be applied to any sc=
alar type,</div></div></blockquote><div><br>I do have a more general class =
template, but it sets moved-from values to their value-initialized state (s=
o supports anything that is DefaultConstructible.) It hadn't occurred to me=
 to use a non-type template parameter as the moved-from value, thanks.<br>&=
nbsp;</div><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_9_12508181.1373459282816--

.