Topic: optional_ptr - A smart pointer which
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 24 Sep 2015 22:47:59 +0300
Raw View
On 24.09.2015 21:21, Matthew Fioravante wrote:
>
> On Thursday, September 24, 2015 at 12:54:55 PM UTC-4, Andrey Semashev wrote:
>
> On Thu, Sep 24, 2015 at 7:35 PM, Matthew Fioravante
> <_fmatth...@gmail.com_ <javascript:>> wrote:
> > For all resources, we have owners who manage the lifetime of the
> resource
> > and viewers who view the resource. To be correct, all of the
> viewers have to
> > stop using the pointer before the last owner goes out of scope
> and destroys
> > the resource.
>
> If anything, this sounds fragile and dangerous.
>
> This was my concern as well and what I anticipate to be the biggest
> argument against this idiom. However I'm not yet entirely convinced that
> its any less dangerous to the situation where you have a
> unique_ptr owned by A and viewed by B as a T*. Its up to the programmer
> to ensure that B's lifetime is within A's lifetime.
> If someone can identify a situation where optional_ptr is much more
> dangerous than unique_ptr/T* that would be really helpful.
unique_ptr/T* and optional_ptr are significantly different. You can use
unique_ptr and raw pointers to the same object because you know who owns
the object and is responsible for its deletion - the unique_ptr. With
optional_ptr there is no distinction (on the interface level) and you
are much more likely to destroy the owning optional_ptr leaving other
optional_ptrs dangling.
> But, in case you can easily guarantee that the owner outlives the
> viewers, did you consider using unique_ptr with a custom deleter?
>
> I'm not sure how a custom deleter would help. If the deleter does
> nothing, then you just have T*, if the deleter conditionally deletes the
> object based on a boolean state, you have my optional_ptr. A reusable
> common pattern should have a name, not be a backwards hack on a
> unique_ptr deleter.
Using unique_ptr with a no-op deleter (a.k.a. null_deleter) is not much
different from using a raw pointer. I'm assuming you want
optional_ptr<T> type to be independent from whether it actually deletes
the object or not. So yes, I was suggesting something like this:
struct optional_deleter
{
optional_deleter() noexcept : m_f(false) {}
explicit optional_deleter(bool f) noexcept : m_f(f) {}
optional_deleter(optional_deleter&& that) noexcept : m_f(that.m_f)
{
that.m_f = false;
}
optional_deleter& operator= (optional_deleter&& that) noexcept
{
m_f = that.m_f;
that.m_f = false;
return *this;
}
template< typename T >
void operator() (T* p) const noexcept
{
if (m_f)
delete p;
}
private:
bool m_f;
};
template< typename T >
using optional_ptr = unique_ptr< T, optional_deleter >;
--
---
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/.
.
Author: Christopher Horvath <blackencino@gmail.com>
Date: Tue, 29 Sep 2015 15:57:06 -0700
Raw View
--001a113f8e26ac38a30520eabb92
Content-Type: text/plain; charset=UTF-8
I also run into this pattern fairly frequently. An example is in an OpenGL
renderer, where a user may want to share vertex buffers between multiple
meshes, but the default case is for the meshes to have unique vertex
buffers. Right now, in different implementations I have one solution where
everything is managed in one central place, which avoids having to use
shared_ptr by making everything's reference essentially a weak_ptr.
However, this is a brittle design and requires frequent changes to multiple
code locations. A much better solution would be to have this optional_ptr
(or whatever it ends up being called, I agree that optional_ptr is a bad
name), instead of what I have now:
// This is a sketch, please don't over-criticize!
class Mesh {
private:
std::unique_ptr<VertexBuffer> m_unique_positions;
std::shared_ptr<VertexBuffer> m_shared_positions;
public:
// This assumes the invariant that one of the two pointers is non-null,
enforced elsewhere
VertexBuffer& getVertexBuffer() { return m_unique_positions ?
*m_unique_positions : *m_shared_positions; }
};
C
On Tue, Sep 29, 2015 at 3:43 PM, Ross Smith <ross.smith@otoy.com> wrote:
> On 2015-09-30 07:38, Bengt Gustafsson wrote:
>
>> I see this pattern quite often. Usually you want to keep the option open
>> to send a pointer to a by value member to conserve allocations. Often in
>> framework code when you want to keep options open for framework users.
>>
>>
> One place I frequently need an optionally-owning pointer is in simple
> command line utilities, where the user can optionally supply a file name to
> read from (or write to), with a filename of "-" traditionally meaning "read
> from standard input" (or "write to standard output"). So a lot of programs
> intended to be run from the command line start with code like this (error
> checking skipped for simplicity):
>
> string filename = argv[1];
> shared_ptr<istream> in;
> if (filename == "-")
> in.reset(&cin, [] (void*) {});
> else
> in = make_shared<ifstream>(filename);
> string line;
> getline(*in, line);
>
> Another situation where I used an optionally-owning pointer recently is in
> an image manipulation class, where the image class object might own the
> image buffer itself, or might be operating on an image owned by some other
> entity.
>
> Ross Smith
>
>
>
> --
>
> --- 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/.
--001a113f8e26ac38a30520eabb92
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I also run into this pattern fairly frequently. An example=
is in an OpenGL renderer, where a user may want to share vertex buffers be=
tween multiple meshes, but the default case is for the meshes to have uniqu=
e vertex buffers.=C2=A0 Right now, in different implementations I have one =
solution where everything is managed in one central place, which avoids hav=
ing to use shared_ptr by making everything's reference essentially a we=
ak_ptr.=C2=A0 However, this is a brittle design and requires frequent chang=
es to multiple code locations.=C2=A0 A much better solution would be to hav=
e this optional_ptr (or whatever it ends up being called, I agree that opti=
onal_ptr is a bad name), instead of what I have now:<div><br></div><div><fo=
nt face=3D"monospace, monospace" size=3D"1">// This is a sketch, please don=
't over-criticize!</font></div><div><font face=3D"monospace, monospace"=
size=3D"1">class Mesh {</font></div><div><font face=3D"monospace, monospac=
e" size=3D"1">private:</font></div><div><font face=3D"monospace, monospace"=
size=3D"1">=C2=A0 =C2=A0 std::unique_ptr<VertexBuffer> m_unique_posi=
tions;</font></div><div><font face=3D"monospace, monospace" size=3D"1">=C2=
=A0 =C2=A0 std::shared_ptr<VertexBuffer> m_shared_positions;</font></=
div><div><font face=3D"monospace, monospace" size=3D"1"><br></font></div><d=
iv><font face=3D"monospace, monospace" size=3D"1">public:</font></div><div>=
<font face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 // This assume=
s the invariant that one of the two pointers is non-null, enforced elsewher=
e</font></div><div><font face=3D"monospace, monospace" size=3D"1">=C2=A0 =
=C2=A0 VertexBuffer& getVertexBuffer() { return m_unique_positions ? *m=
_unique_positions : *m_shared_positions; }</font></div><div><font face=3D"m=
onospace, monospace" size=3D"1">};</font></div><div><br></div><div>C</div><=
div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Tue, Sep 29, 2015 at 3:43 PM, Ross Smith <span dir=3D"ltr"><<a hre=
f=3D"mailto:ross.smith@otoy.com" target=3D"_blank">ross.smith@otoy.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 201=
5-09-30 07:38, Bengt Gustafsson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I see this pattern quite often. Usually you want to keep the option open to=
send a pointer to a by value member to conserve allocations. Often in fram=
ework code when you want to keep options open for framework users.<br>
<br>
</blockquote>
<br></span>
One place I frequently need an optionally-owning pointer is in simple comma=
nd line utilities, where the user can optionally supply a file name to read=
from (or write to), with a filename of "-" traditionally meaning=
"read from standard input" (or "write to standard output&qu=
ot;). So a lot of programs intended to be run from the command line start w=
ith code like this (error checking skipped for simplicity):<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string filename =3D argv[1];<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 shared_ptr<istream> in;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (filename =3D=3D "-")<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in.reset(&cin, [] (void*) {})=
;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in =3D make_shared<ifstream>=
;(filename);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string line;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 getline(*in, line);<br>
<br>
Another situation where I used an optionally-owning pointer recently is in =
an image manipulation class, where the image class object might own the ima=
ge buffer itself, or might be operating on an image owned by some other ent=
ity.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Ross Smith</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--001a113f8e26ac38a30520eabb92--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 30 Sep 2015 07:50:12 -0700 (PDT)
Raw View
------=_Part_198_2008737894.1443624612366
Content-Type: multipart/alternative;
boundary="----=_Part_199_1048050989.1443624612366"
------=_Part_199_1048050989.1443624612366
Content-Type: text/plain; charset=UTF-8
How about generalizing this idea to a erased_ptr<T> which can be
constructed from a unique_ptr&&, a shared_ptr, a weak_ptr or a plain ptr +
bool.
Internally this could be mainly a variant over the different pointer types,
but with an operator-> which works as for any smart pointer. The pointer +
owned == true constructor could maybe be equivalent to sending in a
unique_ptr&&
More thinking is definitely needed but intuitively it seemed to increase
the usefulness to include also shared ownership in the mix.
Den onsdag 30 september 2015 kl. 00:57:09 UTC+2 skrev Christopher Horvath:
>
> I also run into this pattern fairly frequently. An example is in an OpenGL
> renderer, where a user may want to share vertex buffers between multiple
> meshes, but the default case is for the meshes to have unique vertex
> buffers. Right now, in different implementations I have one solution where
> everything is managed in one central place, which avoids having to use
> shared_ptr by making everything's reference essentially a weak_ptr.
> However, this is a brittle design and requires frequent changes to multiple
> code locations. A much better solution would be to have this optional_ptr
> (or whatever it ends up being called, I agree that optional_ptr is a bad
> name), instead of what I have now:
>
> // This is a sketch, please don't over-criticize!
> class Mesh {
> private:
> std::unique_ptr<VertexBuffer> m_unique_positions;
> std::shared_ptr<VertexBuffer> m_shared_positions;
>
> public:
> // This assumes the invariant that one of the two pointers is
> non-null, enforced elsewhere
> VertexBuffer& getVertexBuffer() { return m_unique_positions ?
> *m_unique_positions : *m_shared_positions; }
> };
>
> C
>
>
> On Tue, Sep 29, 2015 at 3:43 PM, Ross Smith <ross....@otoy.com
> <javascript:>> wrote:
>
>> On 2015-09-30 07:38, Bengt Gustafsson wrote:
>>
>>> I see this pattern quite often. Usually you want to keep the option open
>>> to send a pointer to a by value member to conserve allocations. Often in
>>> framework code when you want to keep options open for framework users.
>>>
>>>
>> One place I frequently need an optionally-owning pointer is in simple
>> command line utilities, where the user can optionally supply a file name to
>> read from (or write to), with a filename of "-" traditionally meaning "read
>> from standard input" (or "write to standard output"). So a lot of programs
>> intended to be run from the command line start with code like this (error
>> checking skipped for simplicity):
>>
>> string filename = argv[1];
>> shared_ptr<istream> in;
>> if (filename == "-")
>> in.reset(&cin, [] (void*) {});
>> else
>> in = make_shared<ifstream>(filename);
>> string line;
>> getline(*in, line);
>>
>> Another situation where I used an optionally-owning pointer recently is
>> in an image manipulation class, where the image class object might own the
>> image buffer itself, or might be operating on an image owned by some other
>> entity.
>>
>> Ross Smith
>>
>>
>>
>> --
>>
>> --- 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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_199_1048050989.1443624612366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How about generalizing this idea to a erased_ptr<T> =
which can be constructed from a unique_ptr&&, a shared_ptr, a weak_=
ptr or a plain ptr + bool.<div><br></div><div>Internally this could be main=
ly a variant over the different pointer types, but with an operator-> wh=
ich works as for any smart pointer. The pointer + owned =3D=3D true constru=
ctor could maybe be equivalent to sending in a unique_ptr&&</div><d=
iv><br></div><div>More thinking is definitely needed but intuitively it see=
med to increase the usefulness to include also shared ownership in the mix.=
=C2=A0</div><div><br><br>Den onsdag 30 september 2015 kl. 00:57:09 UTC+2 sk=
rev Christopher Horvath:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I also run into this pattern fairly frequently. An example is in=
an OpenGL renderer, where a user may want to share vertex buffers between =
multiple meshes, but the default case is for the meshes to have unique vert=
ex buffers.=C2=A0 Right now, in different implementations I have one soluti=
on where everything is managed in one central place, which avoids having to=
use shared_ptr by making everything's reference essentially a weak_ptr=
..=C2=A0 However, this is a brittle design and requires frequent changes to =
multiple code locations.=C2=A0 A much better solution would be to have this=
optional_ptr (or whatever it ends up being called, I agree that optional_p=
tr is a bad name), instead of what I have now:<div><br></div><div><font fac=
e=3D"monospace, monospace" size=3D"1">// This is a sketch, please don't=
over-criticize!</font></div><div><font face=3D"monospace, monospace" size=
=3D"1">class Mesh {</font></div><div><font face=3D"monospace, monospace" si=
ze=3D"1">private:</font></div><div><font face=3D"monospace, monospace" size=
=3D"1">=C2=A0 =C2=A0 std::unique_ptr<VertexBuffer> m_unique_positions=
;</font></div><div><font face=3D"monospace, monospace" size=3D"1">=C2=A0 =
=C2=A0 std::shared_ptr<VertexBuffer> m_shared_positions;</font></div>=
<div><font face=3D"monospace, monospace" size=3D"1"><br></font></div><div><=
font face=3D"monospace, monospace" size=3D"1">public:</font></div><div><fon=
t face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 // This assumes th=
e invariant that one of the two pointers is non-null, enforced elsewhere</f=
ont></div><div><font face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0=
VertexBuffer& getVertexBuffer() { return m_unique_positions ? *m_uniqu=
e_positions : *m_shared_positions; }</font></div><div><font face=3D"monospa=
ce, monospace" size=3D"1">};</font></div><div><br></div><div>C</div><div><b=
r></div></div><div><br><div class=3D"gmail_quote">On Tue, Sep 29, 2015 at 3=
:43 PM, Ross Smith <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"3nBhwMIZCgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">ross....@otoy.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span>On 2015-09-30 07:38, Bengt Gustafs=
son wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I see this pattern quite often. Usually you want to keep the option open to=
send a pointer to a by value member to conserve allocations. Often in fram=
ework code when you want to keep options open for framework users.<br>
<br>
</blockquote>
<br></span>
One place I frequently need an optionally-owning pointer is in simple comma=
nd line utilities, where the user can optionally supply a file name to read=
from (or write to), with a filename of "-" traditionally meaning=
"read from standard input" (or "write to standard output&qu=
ot;). So a lot of programs intended to be run from the command line start w=
ith code like this (error checking skipped for simplicity):<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string filename =3D argv[1];<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 shared_ptr<istream> in;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (filename =3D=3D "-")<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in.reset(&cin, [] (void*) {})=
;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in =3D make_shared<ifstream>=
;(<wbr>filename);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string line;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 getline(*in, line);<br>
<br>
Another situation where I used an optionally-owning pointer recently is in =
an image manipulation class, where the image class object might own the ima=
ge buffer itself, or might be operating on an image owned by some other ent=
ity.<span><font color=3D"#888888"><br>
<br>
Ross Smith</font></span><div><div><br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
3nBhwMIZCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"3nBhwMIZCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
------=_Part_199_1048050989.1443624612366--
------=_Part_198_2008737894.1443624612366--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 30 Sep 2015 08:11:53 -0700 (PDT)
Raw View
------=_Part_280_58563333.1443625913883
Content-Type: multipart/alternative;
boundary="----=_Part_281_97292893.1443625913883"
------=_Part_281_97292893.1443625913883
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 30, 2015 at 10:50:12 AM UTC-4, Bengt Gustafsson
wrote:
>
> How about generalizing this idea to a erased_ptr<T> which can be
> constructed from a unique_ptr&&, a shared_ptr, a weak_ptr or a plain ptr +
> bool.
>
While the erased_ptr construct seems like it might be more generic and
therefore better, I'm reluctant to go down this path because I don't have
any use case which would actually need to use an erased_ptr thats sometimes
unique, sometimes a view, and sometimes shared. Do you have a use case for
this?
Also I'm not sure I like the (ptr, bool) constructor. The original version
I wrote had this but I took it out. There is zero cost to creating a
temporary unique_ptr and moving it in, and by doing so you very clearly
document that you want the optional_ptr to own the resource, much moreso
than ptr, true. Also optional_ptr will be designed to be 100% compatible
with unique_ptr with regards to deleters, so if you have an owned resource
you want to pass in, make the appropriate unique_ptr with deleter and then
move it in.
Compare the following callsites:
void f(optional_ptr<T> ptr);
T* p = new T();
f({p, true});
f(std::unique_ptr<T>(p));
The second stands out much more than the first and doesn't cost anything
after the optimizer inlines it away.
Finally my second concern with erased_ptr is performance. optional_ptr can
be implemented with zero space overhead for all alignof(T) > 1 types and
near zero overhead for retreiving (& with a mask) and deleting the pointer
(check conditional first and then delete).
I think at this point we have enough legitimate use cases from people to
show that this tool is actually a good one when used responsibly and will
benefit many users. Lets open the discussion up to bikeshedding the name.
Pretty much everyone hates optional_ptr, including myself so does anyone
have better ideas?
Here are some ideas:
semi_unique_ptr (this one is my favorite so far)
optionally_unique_ptr
optional_ptr
dynamic_unique_ptr
maybe_unique_ptr
variant_ptr
unique_or_view_ptr
I like the idea of having unique in the name, because this thing works
exactly like a unique_ptr when it has ownership.
--
---
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_281_97292893.1443625913883
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, September 30, 2015 at 10:50:12 AM UTC-4,=
Bengt Gustafsson wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr">How a=
bout generalizing this idea to a erased_ptr<T> which can be construct=
ed from a unique_ptr&&, a shared_ptr, a weak_ptr or a plain ptr + b=
ool.</div></blockquote><div>=C2=A0</div><div>While=C2=A0the erased_ptr=C2=
=A0construct seems like it might be more generic and therefore better, I=
9;m reluctant to go down this path because I don't have any use case wh=
ich would actually need to use an erased_ptr thats sometimes unique, someti=
mes a view, and sometimes shared. Do you have a use case for this?</div><di=
v>=C2=A0</div><div>Also I'm not sure I like the (ptr, bool) constructor=
.. The original version I wrote had this but I took it out. There is zero co=
st to creating a temporary unique_ptr and moving it in, and by doing so you=
very clearly document that you want the optional_ptr to own the resource, =
much moreso than ptr, true. Also optional_ptr will be designed to be 100% c=
ompatible with unique_ptr with regards to deleters, so if you have an owned=
resource you want to pass in, make the appropriate unique_ptr with deleter=
and then move it in.</div><div>=C2=A0</div><div>Compare the following call=
sites:</div><div>=C2=A0</div><div><div style=3D"border: 1px solid rgb(187, =
187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">void=
</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> f=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
>optional_ptr</span><span style=3D"color: rgb(102, 102, 0);" class=3D"style=
d-by-prettify"><</span><span style=3D"color: rgb(0, 0, 0);" class=3D"sty=
led-by-prettify">T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
styled-by-prettify">></span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> ptr</span><span style=3D"color: rgb(102, 102, 0);"=
class=3D"styled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);"=
class=3D"styled-by-prettify"><br><br>T</span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">*</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify"> p </span><span style=3D"color: rgb=
(102, 102, 0);" class=3D"styled-by-prettify">=3D</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color:=
rgb(0, 0, 136);" class=3D"styled-by-prettify">new</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T</span><span style=3D"col=
or: rgb(102, 102, 0);" class=3D"styled-by-prettify">();</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>f</span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">({</span><spa=
n style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">p</span><span=
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">true</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">});<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br=
>f</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y">std</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify">unique_ptr</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
styled-by-prettify"><</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify">T</span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">>(</span><span style=3D"color: rgb(0, 0, 0);"=
class=3D"styled-by-prettify">p</span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"styled-by-prettify">));</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"><br></span></div></code></div><br>The sec=
ond stands out much more than the first and doesn't cost anything after=
the optimizer inlines it away.</div><div>=C2=A0</div><div>Finally my secon=
d concern with erased_ptr is performance. optional_ptr can be implemented w=
ith zero space overhead for=C2=A0all alignof(T) > 1=C2=A0types and near =
zero overhead for retreiving (& with a mask)=C2=A0and deleting the poin=
ter (check conditional first and then delete).</div><div>=C2=A0</div><div>I=
think at this point we have enough legitimate use cases=C2=A0from people t=
o show that this tool is actually a good one when used responsibly and will=
benefit many users. Lets open the discussion up to bikeshedding the name.<=
/div><div>=C2=A0</div><div>Pretty much everyone hates optional_ptr, includi=
ng myself so does anyone have better ideas?</div><div>=C2=A0</div><div>Here=
are some ideas:</div><div>semi_unique_ptr (this one is my favorite so far)=
</div><div>optionally_unique_ptr</div><div>optional_ptr</div><div>dynamic_u=
nique_ptr</div><div>maybe_unique_ptr</div><div>variant_ptr</div><div>unique=
_or_view_ptr</div><div>=C2=A0</div><div>=C2=A0</div><div>I like the idea of=
having unique in the name, because this thing works exactly like a unique_=
ptr when it has ownership.</div><div>=C2=A0</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
------=_Part_281_97292893.1443625913883--
------=_Part_280_58563333.1443625913883--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 30 Sep 2015 15:23:19 -0400
Raw View
--089e013d0ffcf3a7ca0520fbdc31
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 30, 2015 at 11:11 AM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:
>
> On Wednesday, September 30, 2015 at 10:50:12 AM UTC-4, Bengt Gustafsson
> wrote:
>>
>> How about generalizing this idea to a erased_ptr<T> which can be
>> constructed from a unique_ptr&&, a shared_ptr, a weak_ptr or a plain ptr +
>> bool.
>>
>
> While the erased_ptr construct seems like it might be more generic and
> therefore better, I'm reluctant to go down this path because I don't have
> any use case which would actually need to use an erased_ptr thats sometimes
> unique, sometimes a view, and sometimes shared. Do you have a use case for
> this?
>
> Also I'm not sure I like the (ptr, bool) constructor. The original version
> I wrote had this but I took it out. There is zero cost to creating a
> temporary unique_ptr and moving it in, and by doing so you very clearly
> document that you want the optional_ptr to own the resource, much moreso
> than ptr, true. Also optional_ptr will be designed to be 100% compatible
> with unique_ptr with regards to deleters, so if you have an owned resource
> you want to pass in, make the appropriate unique_ptr with deleter and then
> move it in.
>
> Compare the following callsites:
>
> void f(optional_ptr<T> ptr);
>
> T* p = new T();
> f({p, true});
> f(std::unique_ptr<T>(p));
>
> The second stands out much more than the first and doesn't cost anything
> after the optimizer inlines it away.
>
> Finally my second concern with erased_ptr is performance. optional_ptr can
> be implemented with zero space overhead for all alignof(T) > 1 types and
> near zero overhead for retreiving (& with a mask) and deleting the pointer
> (check conditional first and then delete).
>
> I think at this point we have enough legitimate use cases from people to
> show that this tool is actually a good one when used responsibly and will
> benefit many users. Lets open the discussion up to bikeshedding the name.
>
> Pretty much everyone hates optional_ptr, including myself so does anyone
> have better ideas?
>
> Here are some ideas:
> semi_unique_ptr (this one is my favorite so far)
>
semi-unique implies that it is (always) half unique (oxymoron) instead of
sometimes unique. Is it like Schrodinger's cat, in two states at once? No.
(schrodinger_ptr?)
> optionally_unique_ptr
>
correct idea, but long and close to optional
> optional_ptr
>
don't go there
> dynamic_unique_ptr
>
suggests thoughts about dynamic_cast?
> maybe_unique_ptr
>
correct idea
> variant_ptr
>
don't go there
> unique_or_view_ptr
>
correct but long
For naming, I think there are two choices:
- correct & concise
- co-opt a term (& concise)
Correct is always what you strive for, but concise is very important for
our brains as well.
If you can't find a 'nice' correct name, go for co-opting a term. Like
'dynamic' in dynamic_cast really isn't quite the usual English meaning of
dynamic, but it was close, and now it has new meaning in the context of
programming. Or "lazy" for types that delay computation. (Instead of
calling them "delayed computation" types.)
It is actually often _good_ to co-opt a term where the user isn't _quite_
sure what you meant - this forces them to READ THE DOCS, and then they will
not make the wrong assumptions, and easily remember how it works later
(assuming the co-opted term forms a reasonable association with your class).
P.S. concise doesn't necessarily mean short. It means (in this case)
efficient in concepts. Growing up the added room on the back of our house
was called the "back room". If it had to be called "the added room at the
back of the house", it would be harder to talk about, and probably even
harder to _think_ about. Let alone type. Ideally a name is a single
concept, or, at most, 2 together (that form a new concept). Once you go
beyond that, your brain is working to make sure it has understood how the
concepts (ie maybe, unique, ptr) fit together, and is second guessing
itself. (If everyone has become comfortable with unique_ptr as a single
concept, then you have 2 concepts: maybe + unique_ptr.) Again consider
"lazy" (single _connotation_) vs "delayed_computation" (two meanings stuck
together). In the end, they mean the same thing (in the context of
programming), but brains seem to be easier at substituting in the final
concept when seeing/thinking/hearing "lazy" vs seeing/thinking/hearing
"delayed computation".
tl;dr. Sorry.
Tony
>
> I like the idea of having unique in the name, because this thing works
> exactly like a unique_ptr when it has ownership.
>
>
> --
>
> ---
> 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/.
--089e013d0ffcf3a7ca0520fbdc31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Sep 30, 2015 at 11:11 AM, Matthew Fioravante <span dir=3D"ltr">=
<<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew587=
6@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><span class=3D""><br>On Wednesday, September 3=
0, 2015 at 10:50:12 AM UTC-4, Bengt Gustafsson wrote:<blockquote style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,=
204)" class=3D"gmail_quote"><div dir=3D"ltr">How about generalizing this id=
ea to a erased_ptr<T> which can be constructed from a unique_ptr&=
&, a shared_ptr, a weak_ptr or a plain ptr + bool.</div></blockquote><d=
iv>=C2=A0</div></span><div>While=C2=A0the erased_ptr=C2=A0construct seems l=
ike it might be more generic and therefore better, I'm reluctant to go =
down this path because I don't have any use case which would actually n=
eed to use an erased_ptr thats sometimes unique, sometimes a view, and some=
times shared. Do you have a use case for this?</div><div>=C2=A0</div><div>A=
lso I'm not sure I like the (ptr, bool) constructor. The original versi=
on I wrote had this but I took it out. There is zero cost to creating a tem=
porary unique_ptr and moving it in, and by doing so you very clearly docume=
nt that you want the optional_ptr to own the resource, much moreso than ptr=
, true. Also optional_ptr will be designed to be 100% compatible with uniqu=
e_ptr with regards to deleters, so if you have an owned resource you want t=
o pass in, make the appropriate unique_ptr with deleter and then move it in=
..</div><div>=C2=A0</div><div>Compare the following callsites:</div><div>=C2=
=A0</div><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:=
rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0,0)"> f</span><span st=
yle=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">optio=
nal_ptr</span><span style=3D"color:rgb(102,102,0)"><</span><span style=
=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,102,0)">></sp=
an><span style=3D"color:rgb(0,0,0)"> ptr</span><span style=3D"color:rgb(102=
,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br><br>T</span><span st=
yle=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> p </=
span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rg=
b(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">new</span><span style=
=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">();</sp=
an><span style=3D"color:rgb(0,0,0)"><br>f</span><span style=3D"color:rgb(10=
2,102,0)">({</span><span style=3D"color:rgb(0,0,0)">p</span><span style=3D"=
color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><spa=
n style=3D"color:rgb(0,0,136)">true</span><span style=3D"color:rgb(102,102,=
0)">});</span><span style=3D"color:rgb(0,0,0)"><br>f</span><span style=3D"c=
olor:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">std</span><sp=
an style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"=
>unique_ptr</span><span style=3D"color:rgb(102,102,0)"><</span><span sty=
le=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,102,0)">>(<=
/span><span style=3D"color:rgb(0,0,0)">p</span><span style=3D"color:rgb(102=
,102,0)">));</span><span style=3D"color:rgb(0,0,0)"><br></span></div></code=
></div><br>The second stands out much more than the first and doesn't c=
ost anything after the optimizer inlines it away.</div><div>=C2=A0</div><di=
v>Finally my second concern with erased_ptr is performance. optional_ptr ca=
n be implemented with zero space overhead for=C2=A0all alignof(T) > 1=C2=
=A0types and near zero overhead for retreiving (& with a mask)=C2=A0and=
deleting the pointer (check conditional first and then delete).</div><div>=
=C2=A0</div><div>I think at this point we have enough legitimate use cases=
=C2=A0from people to show that this tool is actually a good one when used r=
esponsibly and will benefit many users. Lets open the discussion up to bike=
shedding the name.</div><div>=C2=A0</div><div>Pretty much everyone hates op=
tional_ptr, including myself so does anyone have better ideas?</div><div>=
=C2=A0</div><div>Here are some ideas:</div><div>semi_unique_ptr (this one i=
s my favorite so far)</div></div></blockquote><div><br></div><div>semi-uniq=
ue implies that it is (always) half unique (oxymoron) instead of sometimes =
unique.=C2=A0 Is it like Schrodinger's cat, in two states at once? No. =
(schrodinger_ptr?) <br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>optionally_unique_ptr</div></div=
></blockquote><div><br></div><div>correct idea, but long and close to optio=
nal<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>optional_ptr</div></div></blockquote><div><br></div><di=
v>don't go there<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>dynamic_unique_ptr</div></div></blockq=
uote><div><br></div><div>suggests thoughts about dynamic_cast?<br>=C2=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 dir=3D"ltr"><=
div>maybe_unique_ptr</div></div></blockquote><div><br></div><div>correct id=
ea<br>=C2=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"><di=
v dir=3D"ltr"><div>variant_ptr</div></div></blockquote><div><br></div><div>=
don't go there<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>unique_or_view_ptr</div><div></div></div=
></blockquote><div><br></div><div>correct but long<br>=C2=A0<br><br></div><=
div>For naming, I think there are two choices:<br></div><div>- correct &=
; concise<br></div><div>- co-opt a term (& concise)<br><br></div><div>C=
orrect is always what you strive for, but concise is very important for our=
brains as well.<br><br></div><div>If you can't find a 'nice' c=
orrect name, go for co-opting a term.=C2=A0 Like 'dynamic' in dynam=
ic_cast really isn't quite the usual English meaning of dynamic, but it=
was close, and now it has new meaning in the context of programming.=C2=A0=
Or "lazy" for types that delay computation. (Instead of calling =
them "delayed computation" types.)<br></div><div><br></div><div>I=
t is actually often _good_ to co-opt a term where the user isn't _quite=
_ sure what you meant - this forces them to READ THE DOCS, and then they wi=
ll not make the wrong assumptions, and easily remember how it works later (=
assuming the co-opted term forms a reasonable association with your class).=
<br><br><br></div><div>P.S. concise doesn't necessarily mean short. It =
means (in this case) efficient in concepts.=C2=A0 Growing up the added room=
on the back of our house was called the=20
"back room".=C2=A0 If it had to be called "the added room at=
the back of the=20
house", it would be harder to talk about, and probably even harder to=
=20
_think_ about. Let alone type. Ideally a name is a single concept, or, at m=
ost, 2 together (that form a new concept).=C2=A0 Once you go beyond that, y=
our brain is working to make sure it has understood how the concepts (ie ma=
ybe, unique, ptr) fit together, and is second guessing itself.=C2=A0 (If ev=
eryone has become comfortable with unique_ptr as a single concept, then you=
have 2 concepts: maybe + unique_ptr.)=C2=A0 Again consider "lazy"=
; (single _connotation_) vs "delayed_computation" (two meanings s=
tuck together).=C2=A0 In the end, they mean the same thing (in the context =
of programming), but brains seem to be easier at substituting in the final =
concept when seeing/thinking/hearing "lazy" vs seeing/thinking/he=
aring "delayed computation".<br><br></div><div>tl;dr. Sorry.<br><=
br></div><div>Tony<br><br></div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><div>=C2=A0</div><d=
iv>I like the idea of having unique in the name, because this thing works e=
xactly like a unique_ptr when it has ownership.</div><div>=C2=A0</div>
</div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--089e013d0ffcf3a7ca0520fbdc31--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 30 Sep 2015 16:31:55 -0700
Raw View
--047d7b5d52ca0034410520ff56e8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 30, 2015 at 1:32 PM, <j4cbo@dropbox.com> wrote:
> On Thursday, September 24, 2015 at 9:35:28 AM UTC-7, Matthew Fioravante
> wrote:
>>
>> The heavy handed solution to use shared_ptr everywhere. Now everyone is
>> an owner. Using shared_ptr adds runtime overhead to manage the reference
>> count. The biggest problem with shared_ptr is that once you use it in on=
e
>> place, you have to use it everywhere. Everything now must be dynamically
>> allocated individually. You can't allocate 20 objects in an array and vi=
ew
>> one of them. You can't create objects on the stack or as a data member.
>> Forcing individual dynamic allocation is a performance killer. We use C+=
+
>> because we need to be fast and a big part of being fast beings avoiding
>> allocations or failing that, batching them into fewer allocations of lar=
ge
>> contiguous cache friendly chunks.
>>
>
> You can, with the shared_ptr aliasing constructor (which I just discovere=
d
> yesterday):
> std::shared_ptr<std::vector<Thing>> owner =3D ...;
> std::shared_ptr<Thing> viewer(owner, &(*owner)[5]);
> // viewer shares ownership of the vector but points to a specific
> element
>
> Or, less safe but potentially faster:
> std::vector<Thing> owner =3D ...;
> std::shared_ptr<Thing> viewer(std::shared_ptr<Thing>(), &owner[5]);
> // viewer owns no object (so no atomic inc/dec will happen) but point=
s
> to owner[5]
>
Nit on the latter suggestion:
shared_ptr(shared_ptr<Y>&&, T*) does not exist, so the above makes an
unnecessary copy.
This is more like a defect in the Standard than a problem with the above
idiom, though.
=E2=80=93Arthur
P.S. on a pet peeve topic: The Standard wording is super subtle w.r.t. the
differences between
- an empty object (i.e. one with no control block)
- an expired object (i.e. a weak_ptr with a control block whose strong ref
count is zero)
- an object whose stored pointer is null
In particular, it appears from my current reading of N4296 that after
std::shared_ptr<int> sptr1 =3D nullptr;
std::shared_ptr<int> sptr2 =3D (int *)nullptr;
sptr1 must be an empty object whose stored pointer is null, but
sptr2 must be a *non-empty* object whose stored pointer is null.
--=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/.
--047d7b5d52ca0034410520ff56e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Sep 30, 2015 at 1:32 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:j4cbo@dropbox.com" target=3D"_blank">j4cbo@dropbox.com</a>&=
gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">On Thursday, September 24, 2015 at 9:35:2=
8 AM UTC-7, Matthew Fioravante wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
>The heavy handed solution to use shared_ptr everywhere. Now everyone is an=
owner. Using shared_ptr adds runtime overhead to manage the reference coun=
t. The biggest problem with shared_ptr is that once you use it in one place=
, you have to use it everywhere. Everything now must be dynamically allocat=
ed individually. You can't allocate 20 objects in an array and view one=
of them. You can't create objects on the stack or as a data member. Fo=
rcing individual dynamic allocation is a performance killer. We use C++ bec=
ause we need to be fast and a big part of being fast beings avoiding alloca=
tions or failing that, batching them into fewer allocations of large contig=
uous cache friendly chunks.</div></div></blockquote><div><br></div><div>You=
can, with the shared_ptr aliasing constructor (which I just discovered yes=
terday):</div><div>=C2=A0 =C2=A0 std::shared_ptr<std::vector<Thing>=
;> owner =3D ...;<br></div><div>=C2=A0 =C2=A0 std::shared_ptr<Thing&g=
t; viewer(owner,=C2=A0&(*owner)[5]);<br></div><div><div>=C2=A0 =C2=A0 /=
/ viewer shares ownership of the vector but points to a specific element</d=
iv></div><div><br></div><div>Or, less safe but potentially faster:</div><di=
v>=C2=A0 =C2=A0 std::vector<Thing> owner =3D ...;<br></div><div>=C2=
=A0 =C2=A0 std::shared_ptr<Thing> viewer(std::shared_ptr<Thing>=
(), &owner[5]);</div><div>=C2=A0 =C2=A0 // viewer owns no object (so no=
atomic inc/dec will happen) but points to owner[5]</div></div></blockquote=
><div><br></div><div>Nit on the latter suggestion:</div><div>shared_ptr(sha=
red_ptr<Y>&&, T*) does not exist, so the above makes an unnec=
essary copy.</div><div>This is more like a defect in the Standard than a pr=
oblem with the above idiom, though.</div><div><br></div><div>=E2=80=93Arthu=
r</div><div><br></div><div>P.S. on a pet peeve topic: The Standard wording =
is super subtle w.r.t. the differences between</div><div>- an empty object =
(i.e. one with no control block)</div><div>- an expired object (i.e. a weak=
_ptr with a control block whose strong ref count is zero)</div><div>- an ob=
ject whose stored pointer is null</div><div><br></div><div>In particular, i=
t appears from my current reading of N4296 that after</div><div><br></div><=
div>=C2=A0 =C2=A0 std::shared_ptr<int> sptr1 =3D nullptr;</div><div>=
=C2=A0 =C2=A0 std::shared_ptr<int> sptr2 =3D (int *)nullptr;</div><di=
v><br></div><div>sptr1 must be an empty object whose stored pointer is null=
, but</div><div>sptr2 must be a <i>non-empty</i> object whose stored pointe=
r is null.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--047d7b5d52ca0034410520ff56e8--
.
Author: j4cbo@dropbox.com
Date: Wed, 30 Sep 2015 16:46:40 -0700 (PDT)
Raw View
------=_Part_4904_605814047.1443656800192
Content-Type: multipart/alternative;
boundary="----=_Part_4905_543818424.1443656800192"
------=_Part_4905_543818424.1443656800192
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 30, 2015 at 4:31:57 PM UTC-7, Arthur O'Dwyer wrote:
>
> Nit on the latter suggestion:
> shared_ptr(shared_ptr<Y>&&, T*) does not exist, so the above makes an
> unnecessary copy.
> This is more like a defect in the Standard than a problem with the above
> idiom, though.
>
I'd like a shared_ptr(std::nullptr_t, T*) constructor too. (Would require
some SFINAE in the (nullptr_t, Deleter) constructor to avoid ambiguity.)
Anyone wanna write a proposal? :)
--
---
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_4905_543818424.1443656800192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, September 30, 2015 at 4:31:57 PM UTC-7, Arth=
ur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>Nit on the latter suggestion:=
</div><div>shared_ptr(shared_ptr<Y>&&, T*) does not exist, so=
the above makes an unnecessary copy.</div><div>This is more like a defect =
in the Standard than a problem with the above idiom, though.</div></div></d=
iv></div></blockquote><div><br></div><div>I'd like a shared_ptr(std::nu=
llptr_t, T*) constructor too. (Would require some SFINAE in the (nullptr_t,=
Deleter) constructor to avoid ambiguity.) Anyone wanna write a proposal? :=
)<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
------=_Part_4905_543818424.1443656800192--
------=_Part_4904_605814047.1443656800192--
.