Topic: Controversy and debate: Uninitialized
Author: David Krauss <potswa@gmail.com>
Date: Wed, 18 Jun 2014 09:17:58 +0800
Raw View
--Apple-Mail=_13379618-54A7-4FEE-8CAE-FD6EA3492C15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-18, at 9:09 AM, walter1234 <walter2bz@gmail.com> wrote:
> IMO C++ philosophy is "don't pay for what you don't use" : initialisation=
is a cost, it should be possible to express the fact you can reserve space=
without initialising it;
std::aligned_storage does this.
> I have encountered a situation where extraneous initialisation was a prob=
lem (dealing with an in-order CPU with very severe pipeline and cache hazar=
ds)
>=20
> The solution is better compiler warnings.
Agreed.
> Rust is interesting, it has safe semantics , and benefits from "every blo=
ck is an expression" so its' easier to re-arrange code to keep everything i=
nitialised - but it doesn't guarantee that it can always match C++ for perf=
ormance. (only 'performance is as high as possible without violating safety=
).
>=20
> So before changing C++ to guarantee things are initialised, I would say y=
ou'd need to copy this feature.
I've not more than glanced at Rust, and don't plan to, so perhaps you could=
elaborate. Treating statements as expressions is common to many languages,=
but I don't see the relevance. Do you mean, rather than an if-else stateme=
nt, the language prefers something more like the ternary operator (perhaps=
with tuple un/packing), such that it tends to keep account of the assignme=
nts and you won't forget one?
--=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=_13379618-54A7-4FEE-8CAE-FD6EA3492C15
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"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–18, at 9:09 AM, walter1234 <<a href=3D"mailto:walter2bz@g=
mail.com">walter2bz@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">IMO C++ philosoph=
y is "don't pay for what you don't use" : initialisation is a cost, it shou=
ld be possible to express the fact you can reserve space without initialisi=
ng it;</div></blockquote><div><br></div><div><font face=3D"Courier">std::al=
igned_storage</font> does this.</div><br><blockquote type=3D"cite"><div dir=
=3D"ltr"><div>I have encountered a situation where extraneous initialisatio=
n was a problem (dealing with an in-order CPU with very severe pipeline and=
cache hazards)<br><div><br><div>The solution is better compiler warnings.<=
/div></div></div></div></blockquote><div><br></div>Agreed.</div><div><br><b=
lockquote type=3D"cite"><div dir=3D"ltr"><div><div>Rust is interesting, it =
has safe semantics , and benefits from "every block is an expression" so it=
s' easier to re-arrange code to keep everything initialised - but it doesn'=
t guarantee that it can always match C++ for performance. (only 'performanc=
e is as high as possible without violating safety).</div></div><div><br></d=
iv><div>So before changing C++ to guarantee things are initialised, I would=
say you'd need to copy this feature.</div></div></blockquote><div><br></di=
v></div>I’ve not more than glanced at Rust, and don’t plan to, =
so perhaps you could elaborate. Treating statements as expressions is commo=
n to many languages, but I don’t see the relevance. Do you mean, rath=
er than an if-else statement, the language prefers something more like &nbs=
p;the ternary operator (perhaps with tuple un/packing), such that it tends =
to keep account of the assignments and you won’t forget one?<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=_13379618-54A7-4FEE-8CAE-FD6EA3492C15--
.
Author: walter1234 <walter2bz@gmail.com>
Date: Tue, 17 Jun 2014 18:27:14 -0700 (PDT)
Raw View
------=_Part_1964_17289139.1403054834875
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> I=E2=80=99ve not more than glanced at Rust, and don=E2=80=99t plan to, so=
perhaps you=20
> could elaborate. Treating statements as expressions is common to many=20
> languages, but I don=E2=80=99t see the relevance. Do you mean, rather tha=
n an=20
> if-else statement, the language prefers something more like the ternary=
=20
> operator (perhaps with tuple un/packing), such that it tends to keep=20
> account of the assignments and you won=E2=80=99t forget one?
>
>
[1] you can create scope blocks with temporaries, calculate something , and=
=20
return it to assign to something in the outer scope;
[2] Rust "match" (switch on steroids) has a return value, this is extremely=
=20
versatile , given everything else match can do (destructuring and=20
additional 'if' guards on individual match arms) .=20
This of course removes the case where you assign to something within switch=
=20
arms.
[3] rust's if-else replaces the C++ ternary operator
maybe I'm imagining it, but after using Rust i'm left with the perception=
=20
that these features help you to avoid needing uninitialised variables.
One thing rust doesn't do is have a return value for loops, but I would=20
really like them to add that (and copy python's for...else idea).. the=20
language is still in flux, so its not too late for them.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1964_17289139.1403054834875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word">I=E2=80=99ve not more than glanced at Rust, and =
don=E2=80=99t plan to, so perhaps you could elaborate. Treating statements =
as expressions is common to many languages, but I don=E2=80=99t see the rel=
evance. Do you mean, rather than an if-else statement, the language prefers=
something more like the ternary operator (perhaps with tuple un/pack=
ing), such that it tends to keep account of the assignments and you won=E2=
=80=99t forget one?<div><br></div></div></blockquote><div><br></div><div>[1=
] you can create scope blocks with temporaries, calculate something , and r=
eturn it to assign to something in the outer scope;</div><div>[2] Rust "mat=
ch" (switch on steroids) has a return value, this is extremely versatile , =
given everything else match can do (destructuring and additional 'if' guard=
s on individual match arms) . </div><div>This of course removes the ca=
se where you assign to something within switch arms.</div><div>[3] rust's i=
f-else replaces the C++ ternary operator</div><div><br></div><div>maybe I'm=
imagining it, but after using Rust i'm left with the perception that these=
features help you to avoid needing uninitialised variables.</div><div><br>=
</div><div>One thing rust doesn't do is have a return value for loops, but =
I would really like them to add that (and copy python's for...else idea).. =
the language is still in flux, so its not too late for them.</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_1964_17289139.1403054834875--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 17 Jun 2014 20:17:36 -0700
Raw View
Em ter 17 jun 2014, =E0s 18:39:25, rouslankorneychuk@gmail.com escreveu:
> I don't see how default initialization will actually prevent any bugs. If=
a
> program reads a variable sooner than intended, or if the variable was not
> assigned a value when it was intended, your program still does the wrong
> thing regardless of whether the variable was initialized. The only
> difference is the program behaves more predictably and therefore easier t=
o
> debug, but you can get the same predictability by compiling in debug mode=
..
I actually dispute that it's easier to debug.
If you use a memory debugger like Valgrind, it will be able to point out=20
exactly where an uninitialised variable was used when it was uninitialised.=
If=20
it happens to be initialised to zero, Valgrind can't tell intention.
That's the same reason why you should not reset pointers to null in=20
destructors.
> This might even make certain bugs harder to find because a program that
> would otherwise seemingly fail at random might not exhibit any symptoms
> until it is run under a very specific set of conditions.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.
Author: walter1234 <walter2bz@gmail.com>
Date: Tue, 17 Jun 2014 23:26:55 -0700 (PDT)
Raw View
------=_Part_2098_30291709.1403072815385
Content-Type: text/plain; charset=UTF-8
Ok the nice behaviour of rust is requiring that you usually create
variables by assignment of an initial expression.
I agree, silently initialising to zero would actually be a step backwards.
--
---
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_2098_30291709.1403072815385
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Ok the nice behaviour of rust is requiring that you usually create variables by assignment of an initial expression.<div>I agree, silently initialising to zero would actually be a step backwards.</div><div><br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_2098_30291709.1403072815385--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Wed, 18 Jun 2014 13:39:39 -0700
Raw View
On 6/17/14, Stack Machine <stackmachine@hotmail.com> wrote:
> I think that both sides have some compelling arguments. How about
> this:
> int i; // compiletime error: no initializer
> int i = 0; // initialize to 0
> int i = void; // ok, explicitly uninitialized
> Yes, this does break backwards compatibility, but in a way that
> produces a compiletime error. Conversion tools shouldn't be too
> hard to write either.
Alas, things are not quite so simple. In C, "int i;" at global
scope is a tentative definition. That is, it is a definition only
in the absence of a stronger definition. Constructs like this may
still appear in systems headers.
--
Lawrence Crowl
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Wed, 18 Jun 2014 14:34:10 -0700
Raw View
Em qua 18 jun 2014, =E0s 13:39:39, Lawrence Crowl escreveu:
> Alas, things are not quite so simple. In C, "int i;" at global
> scope is a tentative definition. That is, it is a definition only
> in the absence of a stronger definition. Constructs like this may
> still appear in systems headers.
Only in C mode. Such a code already is a full definition in C++, since C++ =
does=20
not support "common" definitions.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.