Topic: noexcept node-based containers (N4055)
Author: David Krauss <potswa@gmail.com>
Date: Sun, 10 Aug 2014 08:17:51 +0800
Raw View
--Apple-Mail=_86D0ABC2-96D0-493E-9789-77965565435C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
The problem with exception-safe node-based container constructors is a dile=
mma:
1. Some algorithms expect swap() to swap the the sentry (dummy node) refere=
nced by end(). This requires it to be allocated on the heap by the default =
and move constructors.
2. Keeping the sentry inside the container object avoids the heap and allow=
s the default and move constructors to be noexcept.
N4055 notes that programs depending on (1) already do not port to platforms=
implementing (2). I think the knot might be untied with the addition of a =
function which adds negligible overhead to platforms with (2) and is a no-o=
p on (1). Such programs could be made portable by simply adding this functi=
on call following the construction of any such container. Then there's a pa=
th to deprecate (1) and add the noexcept specs.
The function might be called detach_end(). The effect is to make the sentry=
swappable. The enabling change (and added complexity) is that the end node=
should be found by the "next" pointer of the container-internal sentry, ra=
ther than being the sentry itself. This requires that pointer to exist, and=
not to be reused for anything else. However, my impression is that existin=
g implementations already tend to implement the pointer and set it to a cir=
cular reference. (Following this proposal, a circular reference would still=
implement non-swappable end().) As for overhead, end() would become equiva=
lent to begin() instead of being potentially slightly faster. And, swap and=
move would need to avoid touching circular references.
detach_end() would invalidate existing end iterators. It would be non-noexc=
ept and non-const.
A new interface function is appropriate because the two implementation styl=
es are suitable for different algorithms. The user should decide which kind=
of end iterator a container gets, not the library vendor. (And, all implem=
entations should support algorithms that assume std::list move operations c=
leanly transplant ranges.)=20
I might be optimistic to assume that implementations are otherwise insensit=
ive to the location of the sentry, and it would require an ABI change. The =
proof has to be in the pudding, but it sounds better, and certainly more ap=
propriate, than emptier-than-empty.
--=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/.
--Apple-Mail=_86D0ABC2-96D0-493E-9789-77965565435C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;">The problem with e=
xception-safe node-based container constructors is a dilemma:<div><br></div=
><div>1. Some algorithms expect <font face=3D"Courier">swap()</font> to swa=
p the the sentry (dummy node) referenced by <font face=3D"Courier">end()</f=
ont>. This requires it to be allocated on the heap by the default and move =
constructors.</div><div>2. Keeping the sentry inside the container object a=
voids the heap and allows the default and move constructors to be <font fac=
e=3D"Courier">noexcept</font>.</div><div><br></div><div>N4055 notes that pr=
ograms depending on (1) already do not port to platforms implementing (2). =
I think the knot might be untied with the addition of a function which adds=
negligible overhead to platforms with (2) and is a no-op on (1). Such prog=
rams could be made portable by simply adding this function call following&n=
bsp;the construction of any such container. Then there’s a path to de=
precate (1) and add the <font face=3D"Courier">noexcept</font> specs.</div>=
<div><br></div><div>The function might be called <font face=3D"Courier">det=
ach_end()</font>. The effect is to make the sentry swappable. The enabling =
change (and added complexity) is that the end node should be found by the &=
ldquo;next” pointer of the container-internal sentry, rather than bei=
ng the sentry itself. This requires that pointer to exist, and not to be re=
used for anything else. However, my impression is that existing implementat=
ions already tend to implement the pointer and set it to a circular referen=
ce. (Following this proposal, a circular reference would still implement no=
n-swappable <font face=3D"Courier">end()</font>.) As for overhead, <font fa=
ce=3D"Courier">end()</font> would become equivalent to <font face=3D"C=
ourier">begin()</font> instead of being potentially slightly faster. And, <=
font face=3D"Courier">swap</font> and <font face=3D"Courier">move</font> wo=
uld need to avoid touching circular references.</div><div><br></div><div><f=
ont face=3D"Courier">detach_end()</font> would invalidate existing end=
iterators. It would be non-<font face=3D"Courier">noexcept</font> and non-=
<font face=3D"Courier">const</font>.</div><div><br></div><div>A new interfa=
ce function is appropriate because the two implementation styles are suitab=
le for different algorithms. The user should decide which kind of end itera=
tor a container gets, not the library vendor. (And, all implementations sho=
uld support algorithms that assume <font face=3D"Courier">std::list</font>&=
nbsp;move operations cleanly transplant ranges.) </div><div><br></div>=
<div>I might be optimistic to assume that implementations are otherwise ins=
ensitive to the location of the sentry, and it would require an ABI change.=
The proof has to be in the pudding, but it sounds better, and certainly mo=
re appropriate, than emptier-than-empty.</div><div><br></div></body></html>
<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 />
--Apple-Mail=_86D0ABC2-96D0-493E-9789-77965565435C--
.
Author: "Stephan T. Lavavej" <stl@exchange.microsoft.com>
Date: Mon, 11 Aug 2014 20:34:19 +0000
Raw View
--_000_4834c666ef6e4523845fdd78b0ad334aBN1PR03MB123namprd03pro_
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> Then there's a path to deprecate (1)
Dynamically allocated sentinel nodes should not be deprecated. While I foc=
us on how they preserve end iterators during swapping/moving just like vect=
ors do, Bill Plauger has argued that dynamically allocated sentinel nodes a=
re necessary to support fancy pointers (reportedly, libstdc++ and libc++ ta=
ke shortcuts which do not respect fancy pointers). I don't pretend to unde=
rstand fancy pointers like Bill does, but I've never heard from anyone with=
a counter to that argument.
> detach_end() would invalidate existing end iterators.
I believe that this would be problematic. What you're proposing is having =
two different kinds of lists - with dynamically-allocated and container-int=
ernal sentinel nodes - sharing the same type. As a result, functions could=
n't exclude one kind or the other through the type system.
> (And, all implementations should support algorithms that assume std::list=
move operations cleanly transplant ranges.)
I don't understand what this means. Moving a list with a container-interna=
l sentinel node will invalidate its end iterators, by definition. But sinc=
e algorithms work on ranges, not containers, this doesn't affect them.
> The proof has to be in the pudding, but it sounds better, and certainly m=
ore appropriate, than emptier-than-empty.
Users shouldn't be doing anything with moved-from objects except destroying=
them or reassigning them, but I've never been able to convince anyone that=
emptier-than-empty would be perfectly reasonable, so I've stopped trying.
STL
From: David Krauss [mailto:potswa@gmail.com]
Sent: Saturday, August 09, 2014 5:18 PM
To: std-proposals@isocpp.org
Cc: Stephan T. Lavavej
Subject: noexcept node-based containers (N4055)
The problem with exception-safe node-based container constructors is a dile=
mma:
1. Some algorithms expect swap() to swap the the sentry (dummy node) refere=
nced by end(). This requires it to be allocated on the heap by the default =
and move constructors.
2. Keeping the sentry inside the container object avoids the heap and allow=
s the default and move constructors to be noexcept.
N4055 notes that programs depending on (1) already do not port to platforms=
implementing (2). I think the knot might be untied with the addition of a =
function which adds negligible overhead to platforms with (2) and is a no-o=
p on (1). Such programs could be made portable by simply adding this functi=
on call following the construction of any such container. Then there's a pa=
th to deprecate (1) and add the noexcept specs.
The function might be called detach_end(). The effect is to make the sentry=
swappable. The enabling change (and added complexity) is that the end node=
should be found by the "next" pointer of the container-internal sentry, ra=
ther than being the sentry itself. This requires that pointer to exist, and=
not to be reused for anything else. However, my impression is that existin=
g implementations already tend to implement the pointer and set it to a cir=
cular reference. (Following this proposal, a circular reference would still=
implement non-swappable end().) As for overhead, end() would become equiva=
lent to begin() instead of being potentially slightly faster. And, swap and=
move would need to avoid touching circular references.
detach_end() would invalidate existing end iterators. It would be non-noexc=
ept and non-const.
A new interface function is appropriate because the two implementation styl=
es are suitable for different algorithms. The user should decide which kind=
of end iterator a container gets, not the library vendor. (And, all implem=
entations should support algorithms that assume std::list move operations c=
leanly transplant ranges.)
I might be optimistic to assume that implementations are otherwise insensit=
ive to the location of the sentry, and it would require an ABI change. The =
proof has to be in the pudding, but it sounds better, and certainly more ap=
propriate, than emptier-than-empty.
--=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/.
--_000_4834c666ef6e4523845fdd78b0ad334aBN1PR03MB123namprd03pro_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Verdana","sans-serif";
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">> Then there’s a path to deprecate (1)
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">Dynamically allocated sentinel nodes should not be depre=
cated. While I focus on how they preserve end iterators during swappi=
ng/moving just like vectors do, Bill Plauger has argued that
dynamically allocated sentinel nodes are necessary to support fancy pointe=
rs (reportedly, libstdc++ and libc++ take shortcuts which d=
o not respect fancy pointers). I don't pretend to understand fancy po=
inters like Bill does, but I've never heard from anyone
with a counter to that argument.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">> detach_end() would invalidate existing end ite=
rators.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">I believe that this would be problematic. What you=
're proposing is having two different kinds of lists - with dynamically-all=
ocated and container-internal sentinel nodes - sharing the same
type. As a result, functions couldn't exclude one kind or the other =
through the type system.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">> (And, all implementations should support algorithms=
that assume std::list move operations cleanly transplant ranges.)&nbs=
p;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">I don't understand what this means. Moving a list =
with a container-internal sentinel node will invalidate its end iterators, =
by definition. But since algorithms work on ranges, not containers,
this doesn't affect them.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">> The proof has to be in the pudding, but it sounds b=
etter, and certainly more appropriate, than emptier-than-empty.<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">Users shouldn't be doing anything with moved-from object=
s except destroying them or reassigning them, but I've never been able to c=
onvince anyone that emptier-than-empty would be perfectly
reasonable, so I've stopped trying.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif"">STL<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Verdana","=
;sans-serif""><o:p> </o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"=
;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> David Kr=
auss [mailto:potswa@gmail.com]
<br>
<b>Sent:</b> Saturday, August 09, 2014 5:18 PM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Cc:</b> Stephan T. Lavavej<br>
<b>Subject:</b> noexcept node-based containers (N4055)<o:p></o:p></span></p=
>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">The problem with exception-safe node-based container=
constructors is a dilemma:<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">1. Some algorithms expect <span style=3D"font-family=
:Courier">
swap()</span> to swap the the sentry (dummy node) referenced by <span style=
=3D"font-family:Courier">
end()</span>. This requires it to be allocated on the heap by the default a=
nd move constructors.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">2. Keeping the sentry inside the container object av=
oids the heap and allows the default and move constructors to be
<span style=3D"font-family:Courier">noexcept</span>.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">N4055 notes that programs depending on (1) already d=
o not port to platforms implementing (2). I think the knot might be untied =
with the addition of a function which adds negligible overhead to platforms=
with (2) and is a no-op on (1). Such
programs could be made portable by simply adding this function call follow=
ing the construction of any such container. Then there’s a path =
to deprecate (1) and add the
<span style=3D"font-family:Courier">noexcept</span> specs.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">The function might be called <span style=3D"font-fam=
ily:Courier">
detach_end()</span>. The effect is to make the sentry swappable. The enabli=
ng change (and added complexity) is that the end node should be found by th=
e “next” pointer of the container-internal sentry, rather than =
being the sentry itself. This requires that
pointer to exist, and not to be reused for anything else. However, my impr=
ession is that existing implementations already tend to implement the point=
er and set it to a circular reference. (Following this proposal, a circular=
reference would still implement
non-swappable <span style=3D"font-family:Courier">end()</span>.) As for ov=
erhead, <span style=3D"font-family:Courier">
end()</span> would become equivalent to <span style=3D"font-family:Cou=
rier">begin()</span> instead of being potentially slightly faster. And,
<span style=3D"font-family:Courier">swap</span> and <span style=3D"font-fam=
ily:Courier">
move</span> would need to avoid touching circular references.<o:p></o:p></p=
>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-family:Courier">detach_end()</sp=
an> would invalidate existing end iterators. It would be non-<span sty=
le=3D"font-family:Courier">noexcept</span> and non-<span style=3D"font-fami=
ly:Courier">const</span>.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">A new interface function is appropriate because the =
two implementation styles are suitable for different algorithms. The user s=
hould decide which kind of end iterator a container gets, not the library v=
endor. (And, all implementations should
support algorithms that assume <span style=3D"font-family:Courier">std::li=
st</span> move operations cleanly transplant ranges.) <o:p></o:p>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I might be optimistic to assume that implementations=
are otherwise insensitive to the location of the sentry, and it would requ=
ire an ABI change. The proof has to be in the pudding, but it sounds better=
, and certainly more appropriate,
than emptier-than-empty.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>
<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 />
--_000_4834c666ef6e4523845fdd78b0ad334aBN1PR03MB123namprd03pro_--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 12 Aug 2014 00:00:16 +0300
Raw View
On 11 August 2014 23:34, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
> Users shouldn't be doing anything with moved-from objects except destroying
> them or reassigning them, but I've never been able to convince anyone that
> emptier-than-empty would be perfectly reasonable, so I've stopped trying.
I believe it's perfectly reasonable for a user to expect to be able to walk the
empty range of begin() to end() of a moved-from container. That expectation
makes emptier-than-empty completely unpalatable to me. The same expectation
applies to size()/empty() and probably a handful of other operations. I find it
completely unreasonable for users to have to deal with multiple points where
the lifetime of a container object would almost-end, leading to such a
zombie state
as emptier-than-empty. The ability to assign doesn't make it any better.
Just in case you have curiosity about _why_ that idea gets rejected,
those are my 0.02 on it.
I very much consider the ship to have sailed on emptier-than-empty,
and I think it sailed
well before 1998.
--
---
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: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 11 Aug 2014 16:12:08 -0500
Raw View
--001a11c2259e5858c3050061046d
Content-Type: text/plain; charset=UTF-8
On 11 August 2014 16:00, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:
> That expectation
>
makes emptier-than-empty completely unpalatable to me. The same expectation
> applies to size()/empty() and probably a handful of other operations. I
> find it
> completely unreasonable for users to have to deal with multiple points
> where
> the lifetime of a container object would almost-end, leading to such a
> zombie state
> as emptier-than-empty.
+1
The example we had, which turned out to be a gcc bug, was someone called
clear() on a moved-from container. Functions w/o preconditions ought to
"just work" without users having to externally track the state of standard
library objects.
--
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/.
--001a11c2259e5858c3050061046d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 August 2014 16:00, Ville Voutilainen <span dir=3D"lt=
r"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vil=
le.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">That expectation<br></div></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
makes emptier-than-empty completely unpalatable to me. The same expectation=
<br>
applies to size()/empty() and probably a handful of other operations. I fin=
d it<br>
completely unreasonable for users to have to deal with multiple points wher=
e<br>
the lifetime of a container object would almost-end, leading to such a<br>
zombie state<br>
as emptier-than-empty.</blockquote><div><br></div><div>+1=C2=A0</div><div><=
br></div><div>The example we had, which turned out to be a gcc bug, was som=
eone called clear() on a moved-from container. =C2=A0Functions w/o precondi=
tions ought to "just work" without users having to externally tra=
ck the state of standard library objects.</div>
<div>--=C2=A0<br></div></div>=C2=A0Nevin ":-)" Liber=C2=A0 <ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>>=C2=A0 (847) 691-1404
</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 />
--001a11c2259e5858c3050061046d--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 11 Aug 2014 18:14:35 -0400
Raw View
--001a1133ce6e4f108a050061e189
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 11, 2014 at 5:00 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> I believe it's perfectly reasonable for a user to expect to be able to
> walk the
> empty range of begin() to end() of a moved-from container.
>
The first time I came to C++11 move semantics, one thing which
shocked me is that, the moved-from object is not considered as
destroyed! I learned it after my program crashes.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--001a1133ce6e4f108a050061e189
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 11, 2014 at 5:00 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
<br>
</div>I believe it's perfectly reasonable for a user to expect to be ab=
le to walk the<br>
empty range of begin() to end() of a moved-from container.<br></blockquote>=
</div><br></div><div class=3D"gmail_extra">The first time I came to C++11 m=
ove semantics, one thing which<br>shocked me is that, the moved-from object=
is not considered as<br>
</div><div class=3D"gmail_extra">destroyed!=C2=A0 I learned it after my pro=
gram crashes.<br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- <br>=
Zhihao Yuan, ID lichray<br>The best way to predict the future is to invent =
it.<br>
___________________________________________________<br>4BSD -- <a href=3D"h=
ttp://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/blog4bsd</a>
</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 />
--001a1133ce6e4f108a050061e189--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 12 Aug 2014 01:19:52 +0300
Raw View
On 12 August 2014 01:14, Zhihao Yuan <zy@miator.net> wrote:
> On Mon, Aug 11, 2014 at 5:00 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>>
>> I believe it's perfectly reasonable for a user to expect to be able to
>> walk the
>> empty range of begin() to end() of a moved-from container.
>
>
> The first time I came to C++11 move semantics, one thing which
> shocked me is that, the moved-from object is not considered as
> destroyed! I learned it after my program crashes.
Yes? It's quite likely that you would get many more crashes if moved-from
objects _were_ considered as destroyed.
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Mon, 11 Aug 2014 18:45:47 -0400
Raw View
--089e01183d4eddf39c05006250fd
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 11, 2014 at 6:19 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 12 August 2014 01:14, Zhihao Yuan <zy@miator.net> wrote:
> > On Mon, Aug 11, 2014 at 5:00 PM, Ville Voutilainen
> > <ville.voutilainen@gmail.com> wrote:
> >>
> >>
> >> I believe it's perfectly reasonable for a user to expect to be able to
> >> walk the
> >> empty range of begin() to end() of a moved-from container.
> >
> >
> > The first time I came to C++11 move semantics, one thing which
> > shocked me is that, the moved-from object is not considered as
> > destroyed! I learned it after my program crashes.
>
>
> Yes? It's quite likely that you would get many more crashes if moved-from
> objects _were_ considered as destroyed.
>
I don't mind crashing more college students' assignments, because...
People... learn real C++ from core dumps... It's not a problem with
how many crashes you encounter in new code, as long as no existing
code is broken.
Whatever... We have two papers proposing destructive move, and I
just want to share some... sympathy.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--089e01183d4eddf39c05006250fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 11, 2014 at 6:19 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">O=
n 12 August 2014 01:14, Zhihao Yuan <<a href=3D"mailto:zy@miator.net">zy=
@miator.net</a>> wrote:<br>
> On Mon, Aug 11, 2014 at 5:00 PM, Ville Voutilainen<br>
> <<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@g=
mail.com</a>> wrote:<br>
>><br>
>><br>
>> I believe it's perfectly reasonable for a user to expect to be=
able to<br>
>> walk the<br>
>> empty range of begin() to end() of a moved-from container.<br>
><br>
><br>
> The first time I came to C++11 move semantics, one thing which<br>
> shocked me is that, the moved-from object is not considered as<br>
> destroyed! =C2=A0I learned it after my program crashes.<br>
<br>
<br>
</div>Yes? It's quite likely that you would get many more crashes if mo=
ved-from<br>
objects _were_ considered as destroyed.<br></blockquote><div><br></div><div=
>I don't mind crashing more college students' assignments, because.=
...<br></div><div>People... learn real C++ from core dumps... It's not a=
problem with<br>
</div><div>how many crashes you encounter in new code, as long as no existi=
ng<br>code is broken.<br><br></div><div>Whatever... We have two papers prop=
osing destructive move, and I<br></div><div>just want to share some... symp=
athy.<br>
</div></div><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict t=
he future is to invent it.<br>_____________________________________________=
______<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http=
://bit.ly/blog4bsd</a>
</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 />
--089e01183d4eddf39c05006250fd--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 12 Aug 2014 01:50:45 +0300
Raw View
On 12 August 2014 01:45, Zhihao Yuan <zy@miator.net> wrote:
>> Yes? It's quite likely that you would get many more crashes if moved-from
>> objects _were_ considered as destroyed.
> I don't mind crashing more college students' assignments, because...
> People... learn real C++ from core dumps... It's not a problem with
> how many crashes you encounter in new code, as long as no existing
> code is broken.
This has nothing to do with any students. Treating moved-from objects
as destroyed _does_ break existing code, and I'm not talking about
school assignments.
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Mon, 11 Aug 2014 18:55:16 -0400
Raw View
--047d7b343682d201210500627242
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 11, 2014 at 6:50 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 12 August 2014 01:45, Zhihao Yuan <zy@miator.net> wrote:
> >> Yes? It's quite likely that you would get many more crashes if
> moved-from
> >> objects _were_ considered as destroyed.
> > I don't mind crashing more college students' assignments, because...
> > People... learn real C++ from core dumps... It's not a problem with
> > how many crashes you encounter in new code, as long as no existing
> > code is broken.
>
> This has nothing to do with any students. Treating moved-from objects
> as destroyed _does_ break existing code, and I'm not talking about
> school assignments.
>
You mean, existing C++98 code? I'm curious, How? C++11 code,
of course.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--047d7b343682d201210500627242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 11, 2014 at 6:50 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">O=
n 12 August 2014 01:45, Zhihao Yuan <<a href=3D"mailto:zy@miator.net">zy=
@miator.net</a>> wrote:<br>
>> Yes? It's quite likely that you would get many more crashes if=
moved-from<br>
>> objects _were_ considered as destroyed.<br>
> I don't mind crashing more college students' assignments, beca=
use...<br>
> People... learn real C++ from core dumps... It's not a problem wit=
h<br>
> how many crashes you encounter in new code, as long as no existing<br>
> code is broken.<br>
<br>
</div>This has nothing to do with any students. Treating moved-from objects=
<br>
as destroyed _does_ break existing code, and I'm not talking about<br>
school assignments.<br></blockquote></div><br></div><div class=3D"gmail_ext=
ra">You mean, existing C++98 code?=C2=A0 I'm curious, How?=C2=A0 C++11 =
code,<br></div><div class=3D"gmail_extra">of course.<br clear=3D"all"></div=
><div class=3D"gmail_extra">
<br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict the future is=
to invent it.<br>___________________________________________________<br>4B=
SD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/bl=
og4bsd</a>
</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 />
--047d7b343682d201210500627242--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 12 Aug 2014 01:57:09 +0300
Raw View
On 12 August 2014 01:55, Zhihao Yuan <zy@miator.net> wrote:
>> This has nothing to do with any students. Treating moved-from objects
>> as destroyed _does_ break existing code, and I'm not talking about
>> school assignments.
> You mean, existing C++98 code? I'm curious, How? C++11 code,
> of course.
Yes, even existing C++98 code, if you happen to get a moved-from container
from beyond an ABI that internally uses C++11.
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Mon, 11 Aug 2014 19:08:53 -0400
Raw View
--001a1132f17e7e12be050062a3c3
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 11, 2014 at 6:57 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 12 August 2014 01:55, Zhihao Yuan <zy@miator.net> wrote:
> >> This has nothing to do with any students. Treating moved-from objects
> >> as destroyed _does_ break existing code, and I'm not talking about
> >> school assignments.
> > You mean, existing C++98 code? I'm curious, How? C++11 code,
> > of course.
>
> Yes, even existing C++98 code, if you happen to get a moved-from container
> from beyond an ABI that internally uses C++11.
>
.... Yes. But we were not talking about the same thing... I was talking
about time machine :(
About *C++11* moved-from state, I have no comment.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--001a1132f17e7e12be050062a3c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 11, 2014 at 6:57 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">O=
n 12 August 2014 01:55, Zhihao Yuan <<a href=3D"mailto:zy@miator.net">zy=
@miator.net</a>> wrote:<br>
>> This has nothing to do with any students. Treating moved-from obje=
cts<br>
>> as destroyed _does_ break existing code, and I'm not talking a=
bout<br>
>> school assignments.<br>
> You mean, existing C++98 code? =C2=A0I'm curious, How? =C2=A0C++11=
code,<br>
> of course.<br>
<br>
</div>Yes, even existing C++98 code, if you happen to get a moved-from cont=
ainer<br>
from beyond an ABI that internally uses C++11.<br></blockquote></div><br></=
div><div class=3D"gmail_extra">... Yes.=C2=A0 But we were not talking about=
the same thing... I was talking<br></div><div class=3D"gmail_extra">about =
time machine :(<br>
<br></div><div class=3D"gmail_extra">About *C++11* moved-from state, I have=
no comment.<br></div><div class=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID=
lichray<br>The best way to predict the future is to invent it.<br>________=
___________________________________________<br>
4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/=
blog4bsd</a>
</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 />
--001a1132f17e7e12be050062a3c3--
.