------=_Part_789_32426934.1352802537852
Content-Type: text/plain; charset=ISO-8859-1

I wonder what are the opinions of other to create a rule that if I type, T
stands for any type (built-in too):

T var_name;

It would mean that var_name would be implicitly initialized with default
value for this type, so the above would be equivalent to:

T var_name = T();

If type doesn't have default value specified the first line could cause an
error do to the lack of proper initializer.

--




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

I wonder what are the opinions of other to create a rule that if I type, T =
stands for any type (built-in too):<div><br></div><div>T var_name;</div><di=
v><br></div><div>It would mean that var_name would be implicitly initialize=
d with default value for this type, so the above would be equivalent to:</d=
iv><div><br></div><div>T var_name =3D T();</div><div><br></div><div>If type=
 doesn't have default value specified the first line could cause an error d=
o to the lack of proper initializer.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_789_32426934.1352802537852--

.

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



W dniu wtorek, 13 listopada 2012 11:28:58 UTC+1 u=BFytkownik Arthur=20
Tchaikovsky napisa=B3:
>
> I wonder what are the opinions of other to create a rule that if I type, =
T=20
> stands for any type (built-in too):
>
> T var_name;
>
> It would mean that var_name would be implicitly initialized with default=
=20
> value for this type, so the above would be equivalent to:
>
> T var_name =3D T();
>
> If type doesn't have default value specified the first line could cause a=
n=20
> error do to the lack of proper initializer.
>

I believe it would be an unacceptable performance penalty in cases where=20
the value is intended to be populated in the next line:=20

T var;
std::cin >> var;


--=20




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

<br><br>W dniu wtorek, 13 listopada 2012 11:28:58 UTC+1 u=BFytkownik Arthur=
 Tchaikovsky napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I wonde=
r what are the opinions of other to create a rule that if I type, T stands =
for any type (built-in too):<div><br></div><div>T var_name;</div><div><br><=
/div><div>It would mean that var_name would be implicitly initialized with =
default value for this type, so the above would be equivalent to:</div><div=
><br></div><div>T var_name =3D T();</div><div><br></div><div>If type doesn'=
t have default value specified the first line could cause an error do to th=
e lack of proper initializer.</div></blockquote><div><br>I believe it would=
 be an unacceptable performance penalty in cases where the value is intende=
d to be populated in the next line: <br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">var</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cin=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">var</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><b=
r></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1437_16900025.1352805413259--

.

------=_Part_189_26093253.1352805503485
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable


=D7=D4=CF=D2=CE=C9=CB, 13 =CE=CF=D1=C2=D2=D1 2012 =C7., 14:28:58 UTC+4 =D0=
=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Arthur Tchaikovsky=20
=CE=C1=D0=C9=D3=C1=CC:
>
> I wonder what are the opinions of other to create a rule that if I type, =
T=20
> stands for any type (built-in too):
>
> T var_name;
>
> It would mean that var_name would be implicitly initialized with default=
=20
> value for this type, so the above would be equivalent to:
>
> T var_name =3D T();
>
> If type doesn't have default value specified the first line could cause a=
n=20
> error do to the lack of proper initializer.
> =20
>
I think that this makes C++ uneffective because every local variable =20
including arrays.has to be initialized though there is no need to do this=
=20
in most cases for local variables.=20

--=20




------=_Part_189_26093253.1352805503485
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<br>=D7=D4=CF=D2=CE=C9=CB, 13 =CE=CF=D1=C2=D2=D1 2012&nbsp;=C7., 14:28:58 U=
TC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Arthur Tchaikovsky =CE=C1=D0=C9=
=D3=C1=CC:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;" class=3D"gmail_quote">I wonder what are the opinions of ot=
her to create a rule that if I type, T stands for any type (built-in too):<=
div><br></div><div>T var_name;</div><div><br></div><div>It would mean that =
var_name would be implicitly initialized with default value for this type, =
so the above would be equivalent to:</div><div><br></div><div>T var_name =
=3D T();</div><div><br></div><div>If type doesn't have default value specif=
ied the first line could cause an error do to the lack of proper initialize=
r.</div><div>&nbsp;</div></blockquote><div>I think that this makes C++&nbsp=
;uneffective because every local variable&nbsp; including arrays.has to be =
initialized though there is no need to do this in most cases&nbsp;for local=
 variables.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_189_26093253.1352805503485--

.

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

@Andrzey && Vlad

Thanks guys for your opinions. Cases like yours could be easily overcome by=
=20
being explicit, which is also helpful to make the intentions of a=20
programmer clear, and write safe and self documenting code. Just out of the=
=20
top of my head:
T var =3D non_init;//this would tell the compiler and the person who will d=
o=20
review of your code, that you actually intended to use uninitialized=20
variable and it is not simply an overlook.

Any thoughts?

On Tuesday, 13 November 2012 11:16:53 UTC, Andrzej Krzemie=F1ski wrote:
>
>
>
> W dniu wtorek, 13 listopada 2012 11:28:58 UTC+1 u=BFytkownik Arthur=20
> Tchaikovsky napisa=B3:
>>
>> I wonder what are the opinions of other to create a rule that if I type,=
=20
>> T stands for any type (built-in too):
>>
>> T var_name;
>>
>> It would mean that var_name would be implicitly initialized with default=
=20
>> value for this type, so the above would be equivalent to:
>>
>> T var_name =3D T();
>>
>> If type doesn't have default value specified the first line could cause=
=20
>> an error do to the lack of proper initializer.
>>
>
> I believe it would be an unacceptable performance penalty in cases where=
=20
> the value is intended to be populated in the next line:=20
>
> T var;
> std::cin >> var;
>
>
>

--=20




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

<div>@Andrzey &amp;&amp; Vlad<br></div><div><br></div><div>Thanks guys for =
your opinions. Cases like yours could be easily overcome by being explicit,=
 which is also helpful to make the intentions of a programmer clear, and wr=
ite safe and self documenting code. Just out of the top of my head:</div><d=
iv>T var =3D non_init;//this would tell the compiler and the person who wil=
l do review of your code, that you actually intended to use uninitialized v=
ariable and it is not simply an overlook.</div><div><br></div><div>Any thou=
ghts?</div><br>On Tuesday, 13 November 2012 11:16:53 UTC, Andrzej Krzemie=
=F1ski  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>W dniu w=
torek, 13 listopada 2012 11:28:58 UTC+1 u=BFytkownik Arthur Tchaikovsky nap=
isa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">I wonder what are the opinio=
ns of other to create a rule that if I type, T stands for any type (built-i=
n too):<div><br></div><div>T var_name;</div><div><br></div><div>It would me=
an that var_name would be implicitly initialized with default value for thi=
s type, so the above would be equivalent to:</div><div><br></div><div>T var=
_name =3D T();</div><div><br></div><div>If type doesn't have default value =
specified the first line could cause an error do to the lack of proper init=
ializer.</div></blockquote><div><br>I believe it would be an unacceptable p=
erformance penalty in cases where the value is intended to be populated in =
the next line: <br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#000">T </span><span style=3D"colo=
r:#008">var</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"><br>std</span><span style=3D"color:#660">::</span><span style=3D"color=
:#000">cin </span><span style=3D"color:#660">&gt;&gt;</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">var</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"><br></span></div></code></div><=
br><br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1615_32610416.1352806875614--

.

On 13 November 2012 13:41, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> Thanks guys for your opinions. Cases like yours could be easily overcome by
> being explicit, which is also helpful to make the intentions of a programmer
> clear, and write safe and self documenting code. Just out of the top of my
> head:
> T var = non_init;//this would tell the compiler and the person who will do
> review of your code, that you actually intended to use uninitialized
> variable and it is not simply an overlook.
> Any thoughts?

It has been floated as an idea a couple of times, but there are
compatibility concerns
to deal with. If you want to make sure your values are initialized, using
T var{};
does that.

Yes, I know it's a work-around, and it's not newbie-friendly. :) However, again,
there's existing code that uses the current rules, and breaking such code
is not something we want to do lightly. Even if it isn't a breakage of
code validity
as such, but breakage of performance characteristics.

--




.

------=_Part_1560_2413263.1352807639484
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that it is already clear enough for a reviewer the actual intention=
=20
of the programmer if he sees a local variable initialized or not.:) I do=20
not think that some comment added to a declaration as for example T var; /*=
=20
this local variable is unitialized */ that equivvalent to T var =3D non_ini=
t=20
will help to read code. Moreover what will be the magic value of non_init?=
=20
Or is it  simply a substitution for the comment shown above?
=20

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 13 =D0=BD=D0=BE=D1=8F=D0=B1=D1=
=80=D1=8F 2012 =D0=B3., 15:41:15 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Arthur Tchaikovsky=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> @Andrzey && Vlad
>
> Thanks guys for your opinions. Cases like yours could be easily overcome=
=20
> by being explicit, which is also helpful to make the intentions of a=20
> programmer clear, and write safe and self documenting code. Just out of t=
he=20
> top of my head:
> T var =3D non_init;//this would tell the compiler and the person who will=
 do=20
> review of your code, that you actually intended to use uninitialized=20
> variable and it is not simply an overlook.
>
> Any thoughts?
>
> On Tuesday, 13 November 2012 11:16:53 UTC, Andrzej Krzemie=C5=84ski wrote=
:
>>
>>
>>
>> W dniu wtorek, 13 listopada 2012 11:28:58 UTC+1 u=C5=BCytkownik Arthur=
=20
>> Tchaikovsky napisa=C5=82:
>>>
>>> I wonder what are the opinions of other to create a rule that if I type=
,=20
>>> T stands for any type (built-in too):
>>>
>>> T var_name;
>>>
>>> It would mean that var_name would be implicitly initialized with defaul=
t=20
>>> value for this type, so the above would be equivalent to:
>>>
>>> T var_name =3D T();
>>>
>>> If type doesn't have default value specified the first line could cause=
=20
>>> an error do to the lack of proper initializer.
>>>
>>
>> I believe it would be an unacceptable performance penalty in cases where=
=20
>> the value is intended to be populated in the next line:=20
>>
>> T var;
>> std::cin >> var;
>>
>>
>>

--=20




------=_Part_1560_2413263.1352807639484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I think that it is already clear enough for a reviewer the actual inte=
ntion of the programmer if&nbsp;he sees a local variable initialized or not=
..:) I do not think that some comment&nbsp;added to a declaration as for exa=
mple T var;&nbsp;/* this local variable is unitialized */ that equivvalent =
to T var =3D non_init will help to read code. Moreover what will be the mag=
ic value of non_init? Or is it&nbsp; simply a substitution for the comment =
shown above?</div><div>&nbsp;</div><div><br>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=
=D0=B8=D0=BA, 13 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2012&nbsp;=D0=B3., 15=
:41:15 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=
=D0=BB=D1=8C Arthur Tchaikovsky =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:=
</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;" class=3D"gmail_quote"><div>@Andrzey &amp;&amp; Vlad<br></div><=
div><br></div><div>Thanks guys for your opinions. Cases like yours could be=
 easily overcome by being explicit, which is also helpful to make the inten=
tions of a programmer clear, and write safe and self documenting code. Just=
 out of the top of my head:</div><div>T var =3D non_init;//this would tell =
the compiler and the person who will do review of your code, that you actua=
lly intended to use uninitialized variable and it is not simply an overlook=
..</div><div><br></div><div>Any thoughts?</div><br>On Tuesday, 13 November 2=
012 11:16:53 UTC, Andrzej Krzemie=C5=84ski  wrote:<blockquote style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_quo=
te"><br><br>W dniu wtorek, 13 listopada 2012 11:28:58 UTC+1 u=C5=BCytkownik=
 Arthur Tchaikovsky napisa=C5=82:<blockquote style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;" class=3D"gmail_quote">I wonder what=
 are the opinions of other to create a rule that if I type, T stands for an=
y type (built-in too):<div><br></div><div>T var_name;</div><div><br></div><=
div>It would mean that var_name would be implicitly initialized with defaul=
t value for this type, so the above would be equivalent to:</div><div><br><=
/div><div>T var_name =3D T();</div><div><br></div><div>If type doesn't have=
 default value specified the first line could cause an error do to the lack=
 of proper initializer.</div></blockquote><div><br>I believe it would be an=
 unacceptable performance penalty in cases where the value is intended to b=
e populated in the next line: <br><br><div style=3D"border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);=
"><code><div><span style=3D"color: rgb(0, 0, 0);">T </span><span style=3D"c=
olor: rgb(0, 0, 136);">var</span><span style=3D"color: rgb(102, 102, 0);">;=
</span><span style=3D"color: rgb(0, 0, 0);"><br>std</span><span style=3D"co=
lor: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);">cin <=
/span><span style=3D"color: rgb(102, 102, 0);">&gt;&gt;</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">va=
r</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=3D"col=
or: rgb(0, 0, 0);"><br></span></div></code></div><br><br></div></blockquote=
></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1560_2413263.1352807639484--

.

------=_Part_657_21715263.1352808291952
Content-Type: text/plain; charset=ISO-8859-1


>
> T var{};
>

I certainly like this workaround.

The problem I tried to resolve is to avoid incidental usage of
uninitialized variables. I don't know how common it is, how much problems
it causes.  The point I'm trying to make with virtually every proposition
of mine is that we should strive to make C++ safe to code "out-of-box", so
uncommon cases (I believe that using uninitialized variable is less common
then initialized) need to be explicitly stated by programmer. As I've said
in my reply to Nicol, I don't care if my idea is going to be accepted or
not. The only thing I care about is to make C++ easy to learn and use.
Safety out of box is something that C++ could be proud of.

On Tuesday, 13 November 2012 11:44:51 UTC, Ville Voutilainen wrote:
>
> On 13 November 2012 13:41, Arthur Tchaikovsky <atch...@gmail.com<javascript:>>
> wrote:
> > Thanks guys for your opinions. Cases like yours could be easily overcome
> by
> > being explicit, which is also helpful to make the intentions of a
> programmer
> > clear, and write safe and self documenting code. Just out of the top of
> my
> > head:
> > T var = non_init;//this would tell the compiler and the person who will
> do
> > review of your code, that you actually intended to use uninitialized
> > variable and it is not simply an overlook.
> > Any thoughts?
>
> It has been floated as an idea a couple of times, but there are
> compatibility concerns
> to deal with. If you want to make sure your values are initialized, using
> T var{};
> does that.
>
> Yes, I know it's a work-around, and it's not newbie-friendly. :) However,
> again,
> there's existing code that uses the current rules, and breaking such code
> is not something we want to do lightly. Even if it isn't a breakage of
> code validity
> as such, but breakage of performance characteristics.
>

--




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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">T var{};<br></blockquote><div>=
<br></div><div>I certainly like this workaround.</div><div><br></div><div>T=
he problem I tried to resolve is to avoid incidental usage of uninitialized=
 variables. I don't know how common it is, how much problems it causes. &nb=
sp;The point I'm trying to make with virtually every proposition of mine is=
 that we should strive to make C++ safe to code "out-of-box", so uncommon c=
ases (I believe that using uninitialized variable is less common then initi=
alized) need to be explicitly stated by programmer. As I've said in my repl=
y to Nicol, I don't care if my idea is going to be accepted or not. The onl=
y thing I care about is to make C++ easy to learn and use. Safety out of bo=
x is something that C++ could be proud of.</div><br>On Tuesday, 13 November=
 2012 11:44:51 UTC, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On 13 November 2012 13:41, Arthur Tchaikovsky &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"kIVWSKaeCUoJ">atch=
....@gmail.com</a>&gt; wrote:
<br>&gt; Thanks guys for your opinions. Cases like yours could be easily ov=
ercome by
<br>&gt; being explicit, which is also helpful to make the intentions of a =
programmer
<br>&gt; clear, and write safe and self documenting code. Just out of the t=
op of my
<br>&gt; head:
<br>&gt; T var =3D non_init;//this would tell the compiler and the person w=
ho will do
<br>&gt; review of your code, that you actually intended to use uninitializ=
ed
<br>&gt; variable and it is not simply an overlook.
<br>&gt; Any thoughts?
<br>
<br>It has been floated as an idea a couple of times, but there are
<br>compatibility concerns
<br>to deal with. If you want to make sure your values are initialized, usi=
ng
<br>T var{};
<br>does that.
<br>
<br>Yes, I know it's a work-around, and it's not newbie-friendly. :) Howeve=
r, again,
<br>there's existing code that uses the current rules, and breaking such co=
de
<br>is not something we want to do lightly. Even if it isn't a breakage of
<br>code validity
<br>as such, but breakage of performance characteristics.
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_657_21715263.1352808291952--

.

On 13 November 2012 14:04, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> The problem I tried to resolve is to avoid incidental usage of uninitialized
> variables. I don't know how common it is, how much problems it causes.  The
> point I'm trying to make with virtually every proposition of mine is that we
> should strive to make C++ safe to code "out-of-box", so uncommon cases (I
> believe that using uninitialized variable is less common then initialized)
> need to be explicitly stated by programmer. As I've said in my reply to
> Nicol, I don't care if my idea is going to be accepted or not. The only
> thing I care about is to make C++ easy to learn and use. Safety out of box
> is something that C++ could be proud of.

It's an admirable goal, and several people have proposed such changes throughout
the years. The (obvious?) problem with incompatible changes is that we have tons
of code using/exploiting/abusing the existing rules. The result of
such proposals for
incompatible changes has usually been to add safe facilities, like the
aforementioned
brace-init, rather than change the existing semantics. Overall that
complicates the
language, sure, but it has the benefit of allowing people to choose between the
safe style and still have access to the unsafe style (which, perhaps
unfortunately,
is the easier-to-write 'default') in a backwards-compatible way. The
compatibility
aspect is considered very important.

--




.

------=_Part_115_338075.1352809205450
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mardi 13 novembre 2012 13:04:52 UTC+1, Arthur Tchaikovsky a =E9crit :
>
> T var{};
>>
>
> I certainly like this workaround.
>
> The problem I tried to resolve is to avoid incidental usage of=20
> uninitialized variables. I don't know how common it is, how much problems=
=20
> it causes.  The point I'm trying to make with virtually every proposition=
=20
> of mine is that we should strive to make C++ safe to code "out-of-box", s=
o=20
> uncommon cases (I believe that using uninitialized variable is less commo=
n=20
> then initialized) need to be explicitly stated by programmer. As I've sai=
d=20
> in my reply to Nicol, I don't care if my idea is going to be accepted or=
=20
> not. The only thing I care about is to make C++ easy to learn and use.=20
> Safety out of box is something that C++ could be proud of.
>

Changing semantic of existing constructs, especially when they exist for=20
such a long time, needs very convincing arguments. As the issue is usually=
=20
know for about as long as the construct existed, I'd start them by=20
considerations about why it hasn't been changed yet and what is different=
=20
now that would make the chance possible.

Static analysis tools and compilers are already doing a good jobs of=20
warning when an uninitialized variable is used. I wouldn't object to a=20
standard attribute helping them to avoid false positive, but I fear that=20
doing more is not possible.

Yours,

--=20
Jean-Marc

--=20




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

Le mardi 13 novembre 2012 13:04:52 UTC+1, Arthur Tchaikovsky a =E9crit&nbsp=
;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">T var{};<br></blockquote><div><br></div><div>I certainly like t=
his workaround.</div><div><br></div><div>The problem I tried to resolve is =
to avoid incidental usage of uninitialized variables. I don't know how comm=
on it is, how much problems it causes. &nbsp;The point I'm trying to make w=
ith virtually every proposition of mine is that we should strive to make C+=
+ safe to code "out-of-box", so uncommon cases (I believe that using uninit=
ialized variable is less common then initialized) need to be explicitly sta=
ted by programmer. As I've said in my reply to Nicol, I don't care if my id=
ea is going to be accepted or not. The only thing I care about is to make C=
++ easy to learn and use. Safety out of box is something that C++ could be =
proud of.</div></blockquote><div><br>Changing semantic of existing construc=
ts, especially when they exist for such a long time, needs very convincing =
arguments. As the issue is usually know for about as long as the construct =
existed, I'd start them by considerations about why it hasn't been changed =
yet and what is different now that would make the chance possible.<br><br>S=
tatic analysis tools and compilers are already doing a good jobs of warning=
 when an uninitialized variable is used. I wouldn't object to a standard at=
tribute helping them to avoid false positive, but I fear that doing more is=
 not possible.<br><br>Yours,<br><br>-- <br>Jean-Marc<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_115_338075.1352809205450--

.

------=_Part_257_30121173.1352826015624
Content-Type: text/plain; charset=ISO-8859-1

I don't think the performance is a problem. If the value is always
overwritten I would expect the compiler to eliminate it, and the
performance of initializing an int is no longer significant. Not having a
default value is just quite irritating.

--




------=_Part_257_30121173.1352826015624
Content-Type: text/html; charset=ISO-8859-1

I don't think the performance is a problem. If the value is always overwritten I would expect the compiler to eliminate it, and the performance of initializing an int is no longer significant. Not having a default value is just quite irritating.

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_257_30121173.1352826015624--

.

------=_Part_15_11435513.1352826651521
Content-Type: text/plain; charset=ISO-8859-1

I personally, strongly believe that we should push towards having C++ safe
"out-of-box". Maybe it will take 5-10 years. Yes, but after this time we
will have beautiful, expressive, powerful and safe language. As the things
go for the moment, I see that C++ will be out of this four I've listed just
powerful. Worse, every new "release" will add more inconsistencies simply
for the sake of not breaking code which someone wrote 20 years ago. This
thinking must change. People must be prepared that their code if they want
to use new, more powerful and safe version of C++, that their code will get
broken in some places. Committee can also issue, let's call it for the
moment, a warning ticket, in which they would specify things to watch for
while compiling with new version of C++. Otherwise I simply see a
Frankenstein. Powerful, but nothing else. It will scare people off. This
isn't good direction for C++.

On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>
> I don't think the performance is a problem. If the value is always
> overwritten I would expect the compiler to eliminate it, and the
> performance of initializing an int is no longer significant. Not having a
> default value is just quite irritating.

--




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

I personally, strongly believe that we should push towards having C++ safe =
"out-of-box". Maybe it will take 5-10 years. Yes, but after this time we wi=
ll have beautiful, expressive, powerful and safe language. As the things go=
 for the moment, I see that C++ will be out of this four I've listed just p=
owerful. Worse, every new "release" will add more inconsistencies simply fo=
r the sake of not breaking code which someone wrote 20 years ago. This thin=
king must change. People must be prepared that their code if they want to u=
se new, more powerful and safe version of C++, that their code will get bro=
ken in some places. Committee can also issue, let's call it for the moment,=
 a warning ticket, in which they would specify things to watch for while co=
mpiling with new version of C++. Otherwise I simply see a Frankenstein. Pow=
erful, but nothing else. It will scare people off. This isn't good directio=
n for C++.<br><br>On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG  wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">I don't think the performance =
is a problem. If the value is always overwritten I would expect the compile=
r to eliminate it, and the performance of initializing an int is no longer =
significant. Not having a default value is just quite irritating.</blockquo=
te>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_15_11435513.1352826651521--

.

------=_Part_1817_14833238.1352826826586
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:
>
> I don't think the performance is a problem. If the value is always
> overwritten I would expect the compiler to eliminate it, and the
> performance of initializing an int is no longer significant. Not having a
> default value is just quite irritating.


Consider this:

struct pod_struct
{
  int i;
  float j;
  double k;
};

void archive(archive &ar, pod_struct &data)
{
  ar & data.i;
  ar & data.j;
  ar & data.k;
}

pod_struct load_pod_from_archive(archive &ar)
{
  pod_struct data;
  archive(ar, data);
  return data;
}



The compiler cannot detect that `archive` is going to fill in `data`. So it
must value-initialize `data` under your new wording, despite the fact that
I'm about to overwrite it. Same goes for overloading `operator>>` for
`pod_struct` and reading it from a stream.

Messing with basic language features like this is a terrible idea and will
only end in tears. Really, what you all seem to want is a completely new
C++ syntax that is equivalent functionally to C++, but with safety by
default. Propose that, get compilers to implement it, whatever, but don't
break C++'s defaults just because they're unpleasant.

Especially when plenty of code relies on them.

--




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

<br><br>On Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">I don't think the performance is a p=
roblem. If the value is always overwritten I would expect the compiler to e=
liminate it, and the performance of initializing an int is no longer signif=
icant. Not having a default value is just quite irritating.</blockquote><di=
v><br>Consider this:<br><br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> pod_struct<br></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> j</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">double</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> k</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> <br><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
rchive</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">archive </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">ar</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> pod_struct </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; ar </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; ar </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> data</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">j</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; ar </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br>pod_struct load_pod_from_=
archive</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">archive </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">ar</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; pod_struct data</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; archive</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">ar</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code>=
</div><br><br><br>The compiler cannot detect that `archive` is going to fil=
l in `data`. So it must value-initialize `data` under your new wording, des=
pite the fact that I'm about to overwrite it. Same goes for overloading `op=
erator&gt;&gt;` for `pod_struct` and reading it from a stream.<br><br>Messi=
ng with basic language features like this is a terrible idea and will only =
end in tears. Really, what you all seem to want is a completely new C++ syn=
tax that is equivalent functionally to C++, but with safety by default. Pro=
pose that, get compilers to implement it, whatever, but don't break C++'s d=
efaults just because they're unpleasant.<br><br>Especially when plenty of c=
ode relies on them.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1817_14833238.1352826826586--

.

------=_Part_7_25016377.1352827039847
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:
>
> I personally, strongly believe that we should push towards having C++ safe
> "out-of-box". Maybe it will take 5-10 years. Yes, but after this time we
> will have beautiful, expressive, powerful and safe language.


No. What you want is a *new language* that is equivalent to C++ but with
safety by default. And I'm not against that. Given that Clang exists now,
it's very possible to make it so that we could losslessly convert C++ code
to this new language.

But you don't want to break *existing code*. Not quietly. People are using
C++ for performance; mess with the performance of their code at your peril.


> As the things go for the moment, I see that C++ will be out of this four
> I've listed just powerful. Worse, every new "release" will add more
> inconsistencies simply for the sake of not breaking code which someone
> wrote 20 years ago. This thinking must change. People must be prepared that
> their code if they want to use new, more powerful and safe version of C++,
> that their code will get broken in some places. Committee can also issue,
> let's call it for the moment, a warning ticket, in which they would specify
> things to watch for while compiling with new version of C++. Otherwise I
> simply see a Frankenstein. Powerful, but nothing else. It will scare people
> off. This isn't good direction for C++.
>

You know what the best way to scare people off from using C++ is? Make them
*rewrite all their code.* Without any form of automated translation tool or
anything.


>
> On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>>
>> I don't think the performance is a problem. If the value is always
>> overwritten I would expect the compiler to eliminate it, and the
>> performance of initializing an int is no longer significant. Not having a
>> default value is just quite irritating.
>
>

--




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

<br><br>On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">I personally, strongly b=
elieve that we should push towards having C++ safe "out-of-box". Maybe it w=
ill take 5-10 years. Yes, but after this time we will have beautiful, expre=
ssive, powerful and safe language.</blockquote><div><br>No. What you want i=
s a <i>new language</i> that is equivalent to C++ but with safety by defaul=
t. And I'm not against that. Given that Clang exists now, it's very possibl=
e to make it so that we could losslessly convert C++ code to this new langu=
age.<br><br>But you don't want to break <i>existing code</i>. Not quietly. =
People are using C++ for performance; mess with the performance of their co=
de at your peril.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"> As the things go for the moment, I see that C++ will be out of this fou=
r I've listed just powerful. Worse, every new "release" will add more incon=
sistencies simply for the sake of not breaking code which someone wrote 20 =
years ago. This thinking must change. People must be prepared that their co=
de if they want to use new, more powerful and safe version of C++, that the=
ir code will get broken in some places. Committee can also issue, let's cal=
l it for the moment, a warning ticket, in which they would specify things t=
o watch for while compiling with new version of C++. Otherwise I simply see=
 a Frankenstein. Powerful, but nothing else. It will scare people off. This=
 isn't good direction for C++.<br></blockquote><div><br>You know what the b=
est way to scare people off from using C++ is? Make them <i>rewrite all the=
ir code.</i> Without any form of automated translation tool or anything.<br=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>On Tuesday, 1=
3 November 2012 17:00:16 UTC, DeadMG  wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">I don't think the performance is a problem. If the value is always=
 overwritten I would expect the compiler to eliminate it, and the performan=
ce of initializing an int is no longer significant. Not having a default va=
lue is just quite irritating.</blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_7_25016377.1352827039847--

.

------=_Part_7_31581196.1352827117141
Content-Type: text/plain; charset=ISO-8859-1

The Python 3.x transition (or rather, the *lack* of a Python 3.x
transition) has shown us that people don't want to change their old code.
They are not going to change their old code. And if you perform major
breaking changes in a widely-used language, they will *revolt* and not
accept it.

On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:
>
>
>
> On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:
>>
>> I personally, strongly believe that we should push towards having C++
>> safe "out-of-box". Maybe it will take 5-10 years. Yes, but after this time
>> we will have beautiful, expressive, powerful and safe language.
>
>
> No. What you want is a *new language* that is equivalent to C++ but with
> safety by default. And I'm not against that. Given that Clang exists now,
> it's very possible to make it so that we could losslessly convert C++ code
> to this new language.
>
> But you don't want to break *existing code*. Not quietly. People are
> using C++ for performance; mess with the performance of their code at your
> peril.
>
>
>> As the things go for the moment, I see that C++ will be out of this four
>> I've listed just powerful. Worse, every new "release" will add more
>> inconsistencies simply for the sake of not breaking code which someone
>> wrote 20 years ago. This thinking must change. People must be prepared that
>> their code if they want to use new, more powerful and safe version of C++,
>> that their code will get broken in some places. Committee can also issue,
>> let's call it for the moment, a warning ticket, in which they would specify
>> things to watch for while compiling with new version of C++. Otherwise I
>> simply see a Frankenstein. Powerful, but nothing else. It will scare people
>> off. This isn't good direction for C++.
>>
>
> You know what the best way to scare people off from using C++ is? Make
> them *rewrite all their code.* Without any form of automated translation
> tool or anything.
>
>
>>
>> On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>>>
>>> I don't think the performance is a problem. If the value is always
>>> overwritten I would expect the compiler to eliminate it, and the
>>> performance of initializing an int is no longer significant. Not having a
>>> default value is just quite irritating.
>>
>>

--




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

The Python 3.x transition (or rather, the <i>lack</i> of a Python 3.x trans=
ition) has shown us that people don't want to change their old code. They a=
re not going to change their old code. And if you perform major breaking ch=
anges in a widely-used language, they will <i>revolt</i> and not accept it.=
<br><br>On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tuesday, November 13=
, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">I personally, strongly believe that we should push towards h=
aving C++ safe "out-of-box". Maybe it will take 5-10 years. Yes, but after =
this time we will have beautiful, expressive, powerful and safe language.</=
blockquote><div><br>No. What you want is a <i>new language</i> that is equi=
valent to C++ but with safety by default. And I'm not against that. Given t=
hat Clang exists now, it's very possible to make it so that we could lossle=
ssly convert C++ code to this new language.<br><br>But you don't want to br=
eak <i>existing code</i>. Not quietly. People are using C++ for performance=
; mess with the performance of their code at your peril.<br>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"> As the things go for the moment, I se=
e that C++ will be out of this four I've listed just powerful. Worse, every=
 new "release" will add more inconsistencies simply for the sake of not bre=
aking code which someone wrote 20 years ago. This thinking must change. Peo=
ple must be prepared that their code if they want to use new, more powerful=
 and safe version of C++, that their code will get broken in some places. C=
ommittee can also issue, let's call it for the moment, a warning ticket, in=
 which they would specify things to watch for while compiling with new vers=
ion of C++. Otherwise I simply see a Frankenstein. Powerful, but nothing el=
se. It will scare people off. This isn't good direction for C++.<br></block=
quote><div><br>You know what the best way to scare people off from using C+=
+ is? Make them <i>rewrite all their code.</i> Without any form of automate=
d translation tool or anything.<br>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><br>On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">I don't think the performance is a pr=
oblem. If the value is always overwritten I would expect the compiler to el=
iminate it, and the performance of initializing an int is no longer signifi=
cant. Not having a default value is just quite irritating.</blockquote></bl=
ockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_7_31581196.1352827117141--

.

------=_Part_1822_27399374.1352827130104
Content-Type: text/plain; charset=ISO-8859-1

Then if you do not want to lose performance or anything else, and have your
old semantic you should do:
pod_struct load_pod_from_archive(archive &ar)
{
  pod_struct data = no_init;
  archive(ar, data);
  return data;
}

and by doing so:
a) you are explicit - code is self documented, no-one may even think that
you've forgot to initialize it
b) you have all of your old unsafe semantics. Simples.


On Tuesday, 13 November 2012 17:13:46 UTC, Nicol Bolas wrote:
>
>
>
> On Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:
>>
>> I don't think the performance is a problem. If the value is always
>> overwritten I would expect the compiler to eliminate it, and the
>> performance of initializing an int is no longer significant. Not having a
>> default value is just quite irritating.
>
>
> Consider this:
>
> struct pod_struct
> {
>   int i;
>   float j;
>   double k;
> };
>
> void archive(archive &ar, pod_struct &data)
> {
>   ar & data.i;
>   ar & data.j;
>   ar & data.k;
> }
>
> pod_struct load_pod_from_archive(archive &ar)
> {
>   pod_struct data;
>   archive(ar, data);
>   return data;
> }
>
>
>
> The compiler cannot detect that `archive` is going to fill in `data`. So
> it must value-initialize `data` under your new wording, despite the fact
> that I'm about to overwrite it. Same goes for overloading `operator>>` for
> `pod_struct` and reading it from a stream.
>
> Messing with basic language features like this is a terrible idea and will
> only end in tears. Really, what you all seem to want is a completely new
> C++ syntax that is equivalent functionally to C++, but with safety by
> default. Propose that, get compilers to implement it, whatever, but don't
> break C++'s defaults just because they're unpleasant.
>
> Especially when plenty of code relies on them.
>

--




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

<div>Then if you do not want to lose performance or anything else, and have=
 your old semantic you should do:<br></div><div>
<span style=3D"color:#000">pod_struct load_pod_from_archive</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">archive </span><span s=
tyle=3D"color:#660">&amp;</span><span style=3D"color:#000">ar</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; pod_struct =
data</span><span style=3D"color:#660"> =3D no_init;</span><span style=3D"co=
lor:#000"><br>&nbsp; archive</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000">ar</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> data</span><span style=3D"color:#660">);</span><span sty=
le=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">return</span=
><span style=3D"color:#000"> data</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span>
</div><div><br></div><div>and by doing so:<br></div><div>a) you are explici=
t - code is self documented, no-one may even think that you've forgot to in=
itialize it</div><div>b) you have all of your old unsafe semantics. Simples=
..</div><div><br></div><div>&nbsp;</div>On Tuesday, 13 November 2012 17:13:4=
6 UTC, Nicol Bolas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>=
<br>On Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">I don't think the performance is a problem. I=
f the value is always overwritten I would expect the compiler to eliminate =
it, and the performance of initializing an int is no longer significant. No=
t having a default value is just quite irritating.</blockquote><div><br>Con=
sider this:<br><br><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-w=
ord"><code><div><span style=3D"color:#008">struct</span><span style=3D"colo=
r:#000"> pod_struct<br></span><span style=3D"color:#660">{</span><span styl=
e=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">int</span><sp=
an style=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">float</spa=
n><span style=3D"color:#000"> j</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">doubl=
e</span><span style=3D"color:#000"> k</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</sp=
an><span style=3D"color:#000"> <br><br></span><span style=3D"color:#008">vo=
id</span><span style=3D"color:#000"> archive</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000">archive </span><span style=3D"color:#=
660">&amp;</span><span style=3D"color:#000">ar</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> pod_struct </span><span style=3D"c=
olor:#660">&amp;</span><span style=3D"color:#000">data</span><span style=3D=
"color:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"><br>&nbsp; ar </span><span st=
yle=3D"color:#660">&amp;</span><span style=3D"color:#000"> data</span><span=
 style=3D"color:#660">.</span><span style=3D"color:#000">i</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; ar </span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000"> data</span=
><span style=3D"color:#660">.</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; ar </s=
pan><span style=3D"color:#660">&amp;</span><span style=3D"color:#000"> data=
</span><span style=3D"color:#660">.</span><span style=3D"color:#000">k</spa=
n><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br>pod_s=
truct load_pod_from_archive</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">archive </span><span style=3D"color:#660">&amp;</span>=
<span style=3D"color:#000">ar</span><span style=3D"color:#660">)</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>&nbsp; pod_struct data</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br>&nbsp; archive</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">ar</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> data</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br>&nbsp; </span><span=
 style=3D"color:#008">return</span><span style=3D"color:#000"> data</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#660">}</span></div></code></div><br><br><br>The compiler=
 cannot detect that `archive` is going to fill in `data`. So it must value-=
initialize `data` under your new wording, despite the fact that I'm about t=
o overwrite it. Same goes for overloading `operator&gt;&gt;` for `pod_struc=
t` and reading it from a stream.<br><br>Messing with basic language feature=
s like this is a terrible idea and will only end in tears. Really, what you=
 all seem to want is a completely new C++ syntax that is equivalent functio=
nally to C++, but with safety by default. Propose that, get compilers to im=
plement it, whatever, but don't break C++'s defaults just because they're u=
npleasant.<br><br>Especially when plenty of code relies on them.<br></div><=
/blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1822_27399374.1352827130104--

.

------=_Part_879_1464273.1352827267453
Content-Type: text/plain; charset=ISO-8859-1

And as for argument that plenty of code relies on them? Call me crazy, I am
more concerned with code which is going to be written and I want to write
new code in safe, compact and expressive way.
I don't believe that having this saying "don't break my code" as a
no-challenger is good for C++

On Tuesday, 13 November 2012 17:18:50 UTC, Arthur Tchaikovsky wrote:
>
> Then if you do not want to lose performance or anything else, and have
> your old semantic you should do:
> pod_struct load_pod_from_archive(archive &ar)
> {
>   pod_struct data = no_init;
>   archive(ar, data);
>   return data;
> }
>
> and by doing so:
> a) you are explicit - code is self documented, no-one may even think that
> you've forgot to initialize it
> b) you have all of your old unsafe semantics. Simples.
>
>
> On Tuesday, 13 November 2012 17:13:46 UTC, Nicol Bolas wrote:
>>
>>
>>
>> On Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:
>>>
>>> I don't think the performance is a problem. If the value is always
>>> overwritten I would expect the compiler to eliminate it, and the
>>> performance of initializing an int is no longer significant. Not having a
>>> default value is just quite irritating.
>>
>>
>> Consider this:
>>
>> struct pod_struct
>> {
>>   int i;
>>   float j;
>>   double k;
>> };
>>
>> void archive(archive &ar, pod_struct &data)
>> {
>>   ar & data.i;
>>   ar & data.j;
>>   ar & data.k;
>> }
>>
>> pod_struct load_pod_from_archive(archive &ar)
>> {
>>   pod_struct data;
>>   archive(ar, data);
>>   return data;
>> }
>>
>>
>>
>> The compiler cannot detect that `archive` is going to fill in `data`. So
>> it must value-initialize `data` under your new wording, despite the fact
>> that I'm about to overwrite it. Same goes for overloading `operator>>` for
>> `pod_struct` and reading it from a stream.
>>
>> Messing with basic language features like this is a terrible idea and
>> will only end in tears. Really, what you all seem to want is a completely
>> new C++ syntax that is equivalent functionally to C++, but with safety by
>> default. Propose that, get compilers to implement it, whatever, but don't
>> break C++'s defaults just because they're unpleasant.
>>
>> Especially when plenty of code relies on them.
>>
>

--




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

<div>And as for argument that plenty of code relies on them? Call me crazy,=
 I am more concerned with code which is going to be written and I want to w=
rite new code in safe, compact and expressive way.<br></div><div>I don't be=
lieve that having this saying "don't break my code" as a no-challenger is g=
ood for C++</div><br>On Tuesday, 13 November 2012 17:18:50 UTC, Arthur Tcha=
ikovsky  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Then if yo=
u do not want to lose performance or anything else, and have your old seman=
tic you should do:<br></div><div>
<span style=3D"color:#000">pod_struct load_pod_from_archive</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">archive </span><span s=
tyle=3D"color:#660">&amp;</span><span style=3D"color:#000">ar</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; pod_struct =
data</span><span style=3D"color:#660"> =3D no_init;</span><span style=3D"co=
lor:#000"><br>&nbsp; archive</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000">ar</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> data</span><span style=3D"color:#660">);</span><span sty=
le=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">return</span=
><span style=3D"color:#000"> data</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span>
</div><div><br></div><div>and by doing so:<br></div><div>a) you are explici=
t - code is self documented, no-one may even think that you've forgot to in=
itialize it</div><div>b) you have all of your old unsafe semantics. Simples=
..</div><div><br></div><div>&nbsp;</div>On Tuesday, 13 November 2012 17:13:4=
6 UTC, Nicol Bolas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>O=
n Tuesday, November 13, 2012 9:00:16 AM UTC-8, DeadMG wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">I don't think the performance is a problem. If the=
 value is always overwritten I would expect the compiler to eliminate it, a=
nd the performance of initializing an int is no longer significant. Not hav=
ing a default value is just quite irritating.</blockquote><div><br>Consider=
 this:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code><div><span style=3D"color:#008">struct</span><span style=3D"color:#00=
0"> pod_struct<br></span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"><br>&nbsp; </span><span style=3D"color:#008">int</span><span st=
yle=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">float</span><s=
pan style=3D"color:#000"> j</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">double</s=
pan><span style=3D"color:#000"> k</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><=
span style=3D"color:#000"> <br><br></span><span style=3D"color:#008">void</=
span><span style=3D"color:#000"> archive</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">archive </span><span style=3D"color:#660"=
>&amp;</span><span style=3D"color:#000">ar</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> pod_struct </span><span style=3D"color=
:#660">&amp;</span><span style=3D"color:#000">data</span><span style=3D"col=
or:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"><br>&nbsp; ar </span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> data</span><span st=
yle=3D"color:#660">.</span><span style=3D"color:#000">i</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; ar </span><sp=
an style=3D"color:#660">&amp;</span><span style=3D"color:#000"> data</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#000">j</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; ar </sp=
an><span style=3D"color:#660">&amp;</span><span style=3D"color:#000"> data<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">k</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br>pod_st=
ruct load_pod_from_archive</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">archive </span><span style=3D"color:#660">&amp;</span><=
span style=3D"color:#000">ar</span><span style=3D"color:#660">)</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>&nbsp; pod_struct data</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br>&nbsp; archive</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">ar</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> data</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"><br>&nbsp; </span><span sty=
le=3D"color:#008">return</span><span style=3D"color:#000"> data</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span></div></code></div><br><br><br>The compiler can=
not detect that `archive` is going to fill in `data`. So it must value-init=
ialize `data` under your new wording, despite the fact that I'm about to ov=
erwrite it. Same goes for overloading `operator&gt;&gt;` for `pod_struct` a=
nd reading it from a stream.<br><br>Messing with basic language features li=
ke this is a terrible idea and will only end in tears. Really, what you all=
 seem to want is a completely new C++ syntax that is equivalent functionall=
y to C++, but with safety by default. Propose that, get compilers to implem=
ent it, whatever, but don't break C++'s defaults just because they're unple=
asant.<br><br>Especially when plenty of code relies on them.<br></div></blo=
ckquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_879_1464273.1352827267453--

.

------=_Part_177_18631041.1352827548088
Content-Type: text/plain; charset=ISO-8859-1


>
> They are not going to change their old code. And if you perform major
> breaking changes in a widely-used language, they will *revolt* and not
> accept it.
>

I dissagree, why?
a) that's only your opinion
b) people did rewrite their C++ code in language far worse than C++, guess
which? C#. Their motivation? Much safer and easier to use. What people I'm
talking about? AutoDesk for example. Their flagship product, my belowed
AutoCad has been rewritten in C#. Why? Why did they go to such extend? Why
doing something in language which is 4 to 12 times slower than C++. Why!
Because for everyday developer C++ as it stands is simply too difficult to
learn/use etc. Just think about it.


On Tuesday, 13 November 2012 17:18:37 UTC, Nicol Bolas wrote:
>
> The Python 3.x transition (or rather, the *lack* of a Python 3.x
> transition) has shown us that people don't want to change their old code.
> They are not going to change their old code. And if you perform major
> breaking changes in a widely-used language, they will *revolt* and not
> accept it.
>
> On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:
>>
>>
>>
>> On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:
>>>
>>> I personally, strongly believe that we should push towards having C++
>>> safe "out-of-box". Maybe it will take 5-10 years. Yes, but after this time
>>> we will have beautiful, expressive, powerful and safe language.
>>
>>
>> No. What you want is a *new language* that is equivalent to C++ but with
>> safety by default. And I'm not against that. Given that Clang exists now,
>> it's very possible to make it so that we could losslessly convert C++ code
>> to this new language.
>>
>> But you don't want to break *existing code*. Not quietly. People are
>> using C++ for performance; mess with the performance of their code at your
>> peril.
>>
>>
>>> As the things go for the moment, I see that C++ will be out of this four
>>> I've listed just powerful. Worse, every new "release" will add more
>>> inconsistencies simply for the sake of not breaking code which someone
>>> wrote 20 years ago. This thinking must change. People must be prepared that
>>> their code if they want to use new, more powerful and safe version of C++,
>>> that their code will get broken in some places. Committee can also issue,
>>> let's call it for the moment, a warning ticket, in which they would specify
>>> things to watch for while compiling with new version of C++. Otherwise I
>>> simply see a Frankenstein. Powerful, but nothing else. It will scare people
>>> off. This isn't good direction for C++.
>>>
>>
>> You know what the best way to scare people off from using C++ is? Make
>> them *rewrite all their code.* Without any form of automated translation
>> tool or anything.
>>
>>
>>>
>>> On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>>>>
>>>> I don't think the performance is a problem. If the value is always
>>>> overwritten I would expect the compiler to eliminate it, and the
>>>> performance of initializing an int is no longer significant. Not having a
>>>> default value is just quite irritating.
>>>
>>>

--




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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
They are not going to change their old code. And if you perform major break=
ing changes in a widely-used language, they will <i>revolt</i> and not acce=
pt it.
<br></blockquote><div><br></div><div>I dissagree, why?<br></div><div>a) tha=
t's only your opinion</div><div>b) people did rewrite their C++ code in lan=
guage far worse than C++, guess which? C#. Their motivation? Much safer and=
 easier to use. What people I'm talking about? AutoDesk for example. Their =
flagship product, my belowed AutoCad has been rewritten in C#. Why? Why did=
 they go to such extend? Why doing something in language which is 4 to 12 t=
imes slower than C++. Why! Because for everyday developer C++ as it stands =
is simply too difficult to learn/use etc. Just think about it.</div><div><b=
r></div><div><br></div>On Tuesday, 13 November 2012 17:18:37 UTC, Nicol Bol=
as  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The Python 3.x trans=
ition (or rather, the <i>lack</i> of a Python 3.x transition) has shown us =
that people don't want to change their old code. They are not going to chan=
ge their old code. And if you perform major breaking changes in a widely-us=
ed language, they will <i>revolt</i> and not accept it.<br><br>On Tuesday, =
November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><br><br>On Tuesday, November 13, 2012 9:10:51 AM UTC-8, =
Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I personal=
ly, strongly believe that we should push towards having C++ safe "out-of-bo=
x". Maybe it will take 5-10 years. Yes, but after this time we will have be=
autiful, expressive, powerful and safe language.</blockquote><div><br>No. W=
hat you want is a <i>new language</i> that is equivalent to C++ but with sa=
fety by default. And I'm not against that. Given that Clang exists now, it'=
s very possible to make it so that we could losslessly convert C++ code to =
this new language.<br><br>But you don't want to break <i>existing code</i>.=
 Not quietly. People are using C++ for performance; mess with the performan=
ce of their code at your peril.<br>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"> As the things go for the moment, I see that C++ will be out of=
 this four I've listed just powerful. Worse, every new "release" will add m=
ore inconsistencies simply for the sake of not breaking code which someone =
wrote 20 years ago. This thinking must change. People must be prepared that=
 their code if they want to use new, more powerful and safe version of C++,=
 that their code will get broken in some places. Committee can also issue, =
let's call it for the moment, a warning ticket, in which they would specify=
 things to watch for while compiling with new version of C++. Otherwise I s=
imply see a Frankenstein. Powerful, but nothing else. It will scare people =
off. This isn't good direction for C++.<br></blockquote><div><br>You know w=
hat the best way to scare people off from using C++ is? Make them <i>rewrit=
e all their code.</i> Without any form of automated translation tool or any=
thing.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>On Tuesda=
y, 13 November 2012 17:00:16 UTC, DeadMG  wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">I don't think the performance is a problem. If the value is al=
ways overwritten I would expect the compiler to eliminate it, and the perfo=
rmance of initializing an int is no longer significant. Not having a defaul=
t value is just quite irritating.</blockquote></blockquote></blockquote></b=
lockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_177_18631041.1352827548088--

.

On 13 November 2012 19:25, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
>> They are not going to change their old code. And if you perform major
>> breaking changes in a widely-used language, they will revolt and not accept
>> it.
> I dissagree, why?
> a) that's only your opinion
> b) people did rewrite their C++ code in language far worse than C++, guess
> which? C#. Their motivation? Much safer and easier to use. What people I'm
> talking about? AutoDesk for example. Their flagship product, my belowed
> AutoCad has been rewritten in C#. Why? Why did they go to such extend? Why
> doing something in language which is 4 to 12 times slower than C++. Why!
> Because for everyday developer C++ as it stands is simply too difficult to
> learn/use etc. Just think about it.

Do you really think autodesk rewrote everything in C#, or do you think they
just added "scriptability" support for C#? I would be astonished if they rewrote
everything, their codebase is large. And such codebases are exactly the reason
why we don't want to make breaking changes, there are many such large codebases
and breaking them causes nothing but harm.

The ease of use of languages like C# and Java is an already dispelled myth.

--




.

------=_Part_11_10278277.1352827900118
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 13, 2012 9:25:48 AM UTC-8, Arthur Tchaikovsky wrote:
>
> They are not going to change their old code. And if you perform major
>> breaking changes in a widely-used language, they will *revolt* and not
>> accept it.
>>
>
> I dissagree, why?
> a) that's only your opinion
>

Informed by *facts*. Again, see Python 3.x adoption (or the lack thereof
among many big Python projects).


> b) people did rewrite their C++ code in language far worse than C++, guess
> which? C#. Their motivation? Much safer and easier to use. What people I'm
> talking about? AutoDesk for example. Their flagship product, my belowed
> AutoCad has been rewritten in C#. Why? Why did they go to such extend? Why
> doing something in language which is 4 to 12 times slower than C++. Why!
> Because for everyday developer C++ as it stands is simply too difficult to
> learn/use etc. Just think about it.
>

And that's exactly the point. Most of the people still using C++ use it *because
it is unsafe*. Unsafe means performance. You're taking one of the most
important reasons why people use C++, something C++ programmers rely on
daily, and telling them that if they want to keep that performance, they
need to update all of their code.

Sorry, that's a non-starter.


> On Tuesday, 13 November 2012 17:18:37 UTC, Nicol Bolas wrote:
>>
>> The Python 3.x transition (or rather, the *lack* of a Python 3.x
>> transition) has shown us that people don't want to change their old code.
>> They are not going to change their old code. And if you perform major
>> breaking changes in a widely-used language, they will *revolt* and not
>> accept it.
>>
>> On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:
>>>>
>>>> I personally, strongly believe that we should push towards having C++
>>>> safe "out-of-box". Maybe it will take 5-10 years. Yes, but after this time
>>>> we will have beautiful, expressive, powerful and safe language.
>>>
>>>
>>> No. What you want is a *new language* that is equivalent to C++ but
>>> with safety by default. And I'm not against that. Given that Clang exists
>>> now, it's very possible to make it so that we could losslessly convert C++
>>> code to this new language.
>>>
>>> But you don't want to break *existing code*. Not quietly. People are
>>> using C++ for performance; mess with the performance of their code at your
>>> peril.
>>>
>>>
>>>> As the things go for the moment, I see that C++ will be out of this
>>>> four I've listed just powerful. Worse, every new "release" will add more
>>>> inconsistencies simply for the sake of not breaking code which someone
>>>> wrote 20 years ago. This thinking must change. People must be prepared that
>>>> their code if they want to use new, more powerful and safe version of C++,
>>>> that their code will get broken in some places. Committee can also issue,
>>>> let's call it for the moment, a warning ticket, in which they would specify
>>>> things to watch for while compiling with new version of C++. Otherwise I
>>>> simply see a Frankenstein. Powerful, but nothing else. It will scare people
>>>> off. This isn't good direction for C++.
>>>>
>>>
>>> You know what the best way to scare people off from using C++ is? Make
>>> them *rewrite all their code.* Without any form of automated
>>> translation tool or anything.
>>>
>>>
>>>>
>>>> On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>>>>>
>>>>> I don't think the performance is a problem. If the value is always
>>>>> overwritten I would expect the compiler to eliminate it, and the
>>>>> performance of initializing an int is no longer significant. Not having a
>>>>> default value is just quite irritating.
>>>>
>>>>

--




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

<br><br>On Tuesday, November 13, 2012 9:25:48 AM UTC-8, Arthur Tchaikovsky =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
They are not going to change their old code. And if you perform major break=
ing changes in a widely-used language, they will <i>revolt</i> and not acce=
pt it.
<br></blockquote><div><br></div><div>I dissagree, why?<br></div><div>a) tha=
t's only your opinion</div></blockquote><div><br>Informed by <i>facts</i>. =
Again, see Python 3.x adoption (or the lack thereof among many big Python p=
rojects).<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
b) people did rewrite their C++ code in language far worse than C++, guess =
which? C#. Their motivation? Much safer and easier to use. What people I'm =
talking about? AutoDesk for example. Their flagship product, my belowed Aut=
oCad has been rewritten in C#. Why? Why did they go to such extend? Why doi=
ng something in language which is 4 to 12 times slower than C++. Why! Becau=
se for everyday developer C++ as it stands is simply too difficult to learn=
/use etc. Just think about it.</div></blockquote><div><br>And that's exactl=
y the point. Most of the people still using C++ use it <i>because it is uns=
afe</i>. Unsafe means performance. You're taking one of the most important =
reasons why people use C++, something C++ programmers rely on daily, and te=
lling them that if they want to keep that performance, they need to update =
all of their code.<br><br>Sorry, that's a non-starter.<br>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div></div>On Tuesday, 13 November =
2012 17:18:37 UTC, Nicol Bolas  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">The Python 3.x transition (or rather, the <i>lack</i> of a Python 3.x tr=
ansition) has shown us that people don't want to change their old code. The=
y are not going to change their old code. And if you perform major breaking=
 changes in a widely-used language, they will <i>revolt</i> and not accept =
it.<br><br>On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, November 13, =
2012 9:10:51 AM UTC-8, Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">I personally, strongly believe that we should push towards hav=
ing C++ safe "out-of-box". Maybe it will take 5-10 years. Yes, but after th=
is time we will have beautiful, expressive, powerful and safe language.</bl=
ockquote><div><br>No. What you want is a <i>new language</i> that is equiva=
lent to C++ but with safety by default. And I'm not against that. Given tha=
t Clang exists now, it's very possible to make it so that we could lossless=
ly convert C++ code to this new language.<br><br>But you don't want to brea=
k <i>existing code</i>. Not quietly. People are using C++ for performance; =
mess with the performance of their code at your peril.<br>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"> As the things go for the moment, I see =
that C++ will be out of this four I've listed just powerful. Worse, every n=
ew "release" will add more inconsistencies simply for the sake of not break=
ing code which someone wrote 20 years ago. This thinking must change. Peopl=
e must be prepared that their code if they want to use new, more powerful a=
nd safe version of C++, that their code will get broken in some places. Com=
mittee can also issue, let's call it for the moment, a warning ticket, in w=
hich they would specify things to watch for while compiling with new versio=
n of C++. Otherwise I simply see a Frankenstein. Powerful, but nothing else=
.. It will scare people off. This isn't good direction for C++.<br></blockqu=
ote><div><br>You know what the best way to scare people off from using C++ =
is? Make them <i>rewrite all their code.</i> Without any form of automated =
translation tool or anything.<br>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><br>On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG  wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">I don't think the performance is a prob=
lem. If the value is always overwritten I would expect the compiler to elim=
inate it, and the performance of initializing an int is no longer significa=
nt. Not having a default value is just quite irritating.</blockquote></bloc=
kquote></blockquote></blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_11_10278277.1352827900118--

.

------=_Part_906_28929843.1352828116793
Content-Type: text/plain; charset=ISO-8859-1


>
> The compiler cannot detect that `archive` is going to fill in `data`. So
> it must value-initialize `data` under your new wording, despite the fact
> that I'm about to overwrite it. Same goes for overloading `operator>>` for
> `pod_struct` and reading it from a stream.


Or it could simply look in the body of archive and see that it does. For
most cases, I think that it will be fine. After all, part of your argument
was that compilers can detect uninitialized reads quite well now- shouldn't
that also hold true for uninitialized writes?

Secondly, I think there is little evidence that in 2012, the performance of
initializing by default is significant. There's a difference between
optimization and premature optimization.

--




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

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">The compiler cannot detect that `archive` is g=
oing to fill in `data`. So it must value-initialize `data` under your new w=
ording, despite the fact that I'm about to overwrite it. Same goes for over=
loading `operator&gt;&gt;` for `pod_struct` and reading it from a stream.</=
blockquote><div><br></div><div>Or it could simply look in the body of archi=
ve and see that it does. For most cases, I think that it will be fine. Afte=
r all, part of your argument was that compilers can detect uninitialized re=
ads quite well now- shouldn't that also hold true for uninitialized writes?=
</div><div><br></div><div>Secondly, I think there is little evidence that i=
n 2012, the performance of initializing by default is significant. There's =
a difference between optimization and premature optimization.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_906_28929843.1352828116793--

.

------=_Part_439_3778351.1352828151303
Content-Type: text/plain; charset=ISO-8859-1


>
> Do you really think autodesk rewrote everything in C#


I nowhere said everything. They definitely rewrote AutoCAD - their flagship
product.

The ease of use of languages like C# and Java is an already dispelled myth


I know about it, my thesis was on this subject. The point I'm making is
that people, if they convinced that the gain outweights costs *will* use
new language.

As for Nicol's argument of performance drop?
a) with my proposal, where only uninitialized (in old code base) variables
are default initialized, I would be more than happy to see actual metrics
and see what is this performance drop, but, even if the performance drop
would prove *to be *significant, it can simply be reversed (the performance
drop) by supplying 'no_init' in front of uninitialized variables. Simples.

On Tuesday, 13 November 2012 17:29:13 UTC, Ville Voutilainen wrote:
>
> On 13 November 2012 19:25, Arthur Tchaikovsky <atch...@gmail.com<javascript:>>
> wrote:
> >> They are not going to change their old code. And if you perform major
> >> breaking changes in a widely-used language, they will revolt and not
> accept
> >> it.
> > I dissagree, why?
> > a) that's only your opinion
> > b) people did rewrite their C++ code in language far worse than C++,
> guess
> > which? C#. Their motivation? Much safer and easier to use. What people
> I'm
> > talking about? AutoDesk for example. Their flagship product, my belowed
> > AutoCad has been rewritten in C#. Why? Why did they go to such extend?
> Why
> > doing something in language which is 4 to 12 times slower than C++. Why!
> > Because for everyday developer C++ as it stands is simply too difficult
> to
> > learn/use etc. Just think about it.
>
> Do you really think autodesk rewrote everything in C#, or do you think
> they
> just added "scriptability" support for C#? I would be astonished if they
> rewrote
> everything, their codebase is large. And such codebases are exactly the
> reason
> why we don't want to make breaking changes, there are many such large
> codebases
> and breaking them causes nothing but harm.
>
> The ease of use of languages like C# and Java is an already dispelled
> myth.
>

--




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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
Do you really think autodesk rewrote everything in C#</blockquote><div>&nbs=
p;</div><div>I nowhere said everything. They definitely rewrote AutoCAD - t=
heir flagship product.&nbsp;</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
The ease of use of languages like C# and Java is an already dispelled myth<=
/blockquote><div><br></div><div>I know about it, my thesis was on this subj=
ect. The point I'm making is that people, if they convinced that the gain o=
utweights costs <em>will</em> use new language. </div><div><br></div><div>A=
s for Nicol's argument of performance drop? </div><div>a) with my proposal,=
 where only uninitialized (in old code base) variables are default initiali=
zed, I would be more than happy to see actual metrics and see what is this =
performance drop, but, even if the performance drop would prove <em>to be <=
/em>significant, it can simply be reversed (the performance drop) by supply=
ing 'no_init' in front of uninitialized variables. Simples.</div><br>On Tue=
sday, 13 November 2012 17:29:13 UTC, Ville Voutilainen  wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">On 13 November 2012 19:25, Arthur Tchaikovs=
ky &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"g=
DwJQ4aoUB8J">atch...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; They are not going to change their old code. And if you perfor=
m major
<br>&gt;&gt; breaking changes in a widely-used language, they will revolt a=
nd not accept
<br>&gt;&gt; it.
<br>&gt; I dissagree, why?
<br>&gt; a) that's only your opinion
<br>&gt; b) people did rewrite their C++ code in language far worse than C+=
+, guess
<br>&gt; which? C#. Their motivation? Much safer and easier to use. What pe=
ople I'm
<br>&gt; talking about? AutoDesk for example. Their flagship product, my be=
lowed
<br>&gt; AutoCad has been rewritten in C#. Why? Why did they go to such ext=
end? Why
<br>&gt; doing something in language which is 4 to 12 times slower than C++=
.. Why!
<br>&gt; Because for everyday developer C++ as it stands is simply too diff=
icult to
<br>&gt; learn/use etc. Just think about it.
<br>
<br>Do you really think autodesk rewrote everything in C#, or do you think =
they
<br>just added "scriptability" support for C#? I would be astonished if the=
y rewrote
<br>everything, their codebase is large. And such codebases are exactly the=
 reason
<br>why we don't want to make breaking changes, there are many such large c=
odebases
<br>and breaking them causes nothing but harm.
<br>
<br>The ease of use of languages like C# and Java is an already dispelled m=
yth.
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_439_3778351.1352828151303--

.

------=_Part_272_2936299.1352828405487
Content-Type: text/plain; charset=ISO-8859-1


>
> And that's exactly the point. Most of the people still using C++ use it
> because it is unsafe.
>

And that is in my eyes old, unimaginative thinking. Why perfomance must
means unsafe? As I proved by providing examples it doesn't. Even more. We
can have self documented, easier to maintain code. What's wrong with that?

Why:
int i = no_init;

is so opposed to? and instead of this we have:
int i;//what on earth the guy was thinking here? Is that on purpose or is
simply an error? Where shall I look for an answer?

The old thinking must change. Otherwise we will end up with unstable,
emotionally distressed Frankenstein.

On Tuesday, 13 November 2012 17:31:40 UTC, Nicol Bolas wrote:
>
>
>
> On Tuesday, November 13, 2012 9:25:48 AM UTC-8, Arthur Tchaikovsky wrote:
>>
>> They are not going to change their old code. And if you perform major
>>> breaking changes in a widely-used language, they will *revolt* and not
>>> accept it.
>>>
>>
>> I dissagree, why?
>> a) that's only your opinion
>>
>
> Informed by *facts*. Again, see Python 3.x adoption (or the lack thereof
> among many big Python projects).
>
>
>> b) people did rewrite their C++ code in language far worse than C++,
>> guess which? C#. Their motivation? Much safer and easier to use. What
>> people I'm talking about? AutoDesk for example. Their flagship product, my
>> belowed AutoCad has been rewritten in C#. Why? Why did they go to such
>> extend? Why doing something in language which is 4 to 12 times slower than
>> C++. Why! Because for everyday developer C++ as it stands is simply too
>> difficult to learn/use etc. Just think about it.
>>
>
> And that's exactly the point. Most of the people still using C++ use it *because
> it is unsafe*. Unsafe means performance. You're taking one of the most
> important reasons why people use C++, something C++ programmers rely on
> daily, and telling them that if they want to keep that performance, they
> need to update all of their code.
>
> Sorry, that's a non-starter.
>
>
>> On Tuesday, 13 November 2012 17:18:37 UTC, Nicol Bolas wrote:
>>>
>>> The Python 3.x transition (or rather, the *lack* of a Python 3.x
>>> transition) has shown us that people don't want to change their old code.
>>> They are not going to change their old code. And if you perform major
>>> breaking changes in a widely-used language, they will *revolt* and not
>>> accept it.
>>>
>>> On Tuesday, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:
>>>>
>>>>
>>>>
>>>> On Tuesday, November 13, 2012 9:10:51 AM UTC-8, Arthur Tchaikovsky
>>>> wrote:
>>>>>
>>>>> I personally, strongly believe that we should push towards having C++
>>>>> safe "out-of-box". Maybe it will take 5-10 years. Yes, but after this time
>>>>> we will have beautiful, expressive, powerful and safe language.
>>>>
>>>>
>>>> No. What you want is a *new language* that is equivalent to C++ but
>>>> with safety by default. And I'm not against that. Given that Clang exists
>>>> now, it's very possible to make it so that we could losslessly convert C++
>>>> code to this new language.
>>>>
>>>> But you don't want to break *existing code*. Not quietly. People are
>>>> using C++ for performance; mess with the performance of their code at your
>>>> peril.
>>>>
>>>>
>>>>> As the things go for the moment, I see that C++ will be out of this
>>>>> four I've listed just powerful. Worse, every new "release" will add more
>>>>> inconsistencies simply for the sake of not breaking code which someone
>>>>> wrote 20 years ago. This thinking must change. People must be prepared that
>>>>> their code if they want to use new, more powerful and safe version of C++,
>>>>> that their code will get broken in some places. Committee can also issue,
>>>>> let's call it for the moment, a warning ticket, in which they would specify
>>>>> things to watch for while compiling with new version of C++. Otherwise I
>>>>> simply see a Frankenstein. Powerful, but nothing else. It will scare people
>>>>> off. This isn't good direction for C++.
>>>>>
>>>>
>>>> You know what the best way to scare people off from using C++ is? Make
>>>> them *rewrite all their code.* Without any form of automated
>>>> translation tool or anything.
>>>>
>>>>
>>>>>
>>>>> On Tuesday, 13 November 2012 17:00:16 UTC, DeadMG wrote:
>>>>>>
>>>>>> I don't think the performance is a problem. If the value is always
>>>>>> overwritten I would expect the compiler to eliminate it, and the
>>>>>> performance of initializing an int is no longer significant. Not having a
>>>>>> default value is just quite irritating.
>>>>>
>>>>>

--




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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">And that's exactly the point. =
Most of the people still using C++ use it because it is unsafe.<br></blockq=
uote><div><br></div><div>And that is in my eyes old, unimaginative thinking=
.. Why perfomance must means unsafe? As I proved by providing examples it do=
esn't. Even more. We can have self documented, easier to maintain code. Wha=
t's wrong with that?</div><div><br></div><div>Why:</div><div>int i =3D no_i=
nit;</div><div><br></div><div>is so opposed to? and instead of this we have=
:</div><div>int i;//what on earth the guy was thinking here? Is that on pur=
pose or is simply an error? Where shall I look for an answer?</div><div><br=
></div><div>The old thinking must change. Otherwise we will end up with uns=
table, emotionally distressed Frankenstein.&nbsp;</div><br>On Tuesday, 13 N=
ovember 2012 17:31:40 UTC, Nicol Bolas  wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><br><br>On Tuesday, November 13, 2012 9:25:48 AM UTC-8, Art=
hur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
They are not going to change their old code. And if you perform major break=
ing changes in a widely-used language, they will <i>revolt</i> and not acce=
pt it.
<br></blockquote><div><br></div><div>I dissagree, why?<br></div><div>a) tha=
t's only your opinion</div></blockquote><div><br>Informed by <i>facts</i>. =
Again, see Python 3.x adoption (or the lack thereof among many big Python p=
rojects).<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>b) pe=
ople did rewrite their C++ code in language far worse than C++, guess which=
? C#. Their motivation? Much safer and easier to use. What people I'm talki=
ng about? AutoDesk for example. Their flagship product, my belowed AutoCad =
has been rewritten in C#. Why? Why did they go to such extend? Why doing so=
mething in language which is 4 to 12 times slower than C++. Why! Because fo=
r everyday developer C++ as it stands is simply too difficult to learn/use =
etc. Just think about it.</div></blockquote><div><br>And that's exactly the=
 point. Most of the people still using C++ use it <i>because it is unsafe</=
i>. Unsafe means performance. You're taking one of the most important reaso=
ns why people use C++, something C++ programmers rely on daily, and telling=
 them that if they want to keep that performance, they need to update all o=
f their code.<br><br>Sorry, that's a non-starter.<br>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On Tuesday, 13 November 2012 17:18:37 UTC, Ni=
col Bolas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The Python 3.x tra=
nsition (or rather, the <i>lack</i> of a Python 3.x transition) has shown u=
s that people don't want to change their old code. They are not going to ch=
ange their old code. And if you perform major breaking changes in a widely-=
used language, they will <i>revolt</i> and not accept it.<br><br>On Tuesday=
, November 13, 2012 9:17:20 AM UTC-8, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><br><br>On Tuesday, November 13, 2012 9:10:51 AM UTC=
-8, Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I pers=
onally, strongly believe that we should push towards having C++ safe "out-o=
f-box". Maybe it will take 5-10 years. Yes, but after this time we will hav=
e beautiful, expressive, powerful and safe language.</blockquote><div><br>N=
o. What you want is a <i>new language</i> that is equivalent to C++ but wit=
h safety by default. And I'm not against that. Given that Clang exists now,=
 it's very possible to make it so that we could losslessly convert C++ code=
 to this new language.<br><br>But you don't want to break <i>existing code<=
/i>. Not quietly. People are using C++ for performance; mess with the perfo=
rmance of their code at your peril.<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"> As the things go for the moment, I see that C++ will be ou=
t of this four I've listed just powerful. Worse, every new "release" will a=
dd more inconsistencies simply for the sake of not breaking code which some=
one wrote 20 years ago. This thinking must change. People must be prepared =
that their code if they want to use new, more powerful and safe version of =
C++, that their code will get broken in some places. Committee can also iss=
ue, let's call it for the moment, a warning ticket, in which they would spe=
cify things to watch for while compiling with new version of C++. Otherwise=
 I simply see a Frankenstein. Powerful, but nothing else. It will scare peo=
ple off. This isn't good direction for C++.<br></blockquote><div><br>You kn=
ow what the best way to scare people off from using C++ is? Make them <i>re=
write all their code.</i> Without any form of automated translation tool or=
 anything.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>On Tu=
esday, 13 November 2012 17:00:16 UTC, DeadMG  wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">I don't think the performance is a problem. If the value i=
s always overwritten I would expect the compiler to eliminate it, and the p=
erformance of initializing an int is no longer significant. Not having a de=
fault value is just quite irritating.</blockquote></blockquote></blockquote=
></blockquote></blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_272_2936299.1352828405487--

.

------=_Part_1668_28762068.1352828543248
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 13, 2012 9:35:51 AM UTC-8, Arthur Tchaikovsky wrote:
>
> Do you really think autodesk rewrote everything in C#
>
>
> I nowhere said everything. They definitely rewrote AutoCAD - their
> flagship product.
>
> The ease of use of languages like C# and Java is an already dispelled myth
>
>
> I know about it, my thesis was on this subject. The point I'm making is
> that people, if they convinced that the gain outweights costs *will* use
> new language.
>
> As for Nicol's argument of performance drop?
> a) with my proposal, where only uninitialized (in old code base) variables
> are default initialized, I would be more than happy to see actual metrics
> and see what is this performance drop, but, even if the performance drop
> would prove *to be *significant, it can simply be reversed (the
> performance drop) by supplying 'no_init' in front of uninitialized
> variables. Simples.
>

You seem to misunderstand how this works. C++ is C++, and maintaining
existing code takes priority, all other things being equal. Therefore, if
you're proposing a feature, it's *you* who needs to provide "actual
metrics". It's *you* who needs to prove that there *isn't* a significant
performance drop. You need to prove, or at least provide real-world
evidence in actual codebases, that this *won't* result in exactly the kind
of problems being stated here.

In short, the burden of proof is always on the new feature, not on current
behavior. The standards committee is not going to make a major change to
the language like that without substantial evidence that it *won't* be
exceptionally harmful. Not when the *only benefit* of this is added safety
(important though that may be).


> On Tuesday, 13 November 2012 17:29:13 UTC, Ville Voutilainen wrote:
>>
>> On 13 November 2012 19:25, Arthur Tchaikovsky <atch...@gmail.com> wrote:
>> >> They are not going to change their old code. And if you perform major
>> >> breaking changes in a widely-used language, they will revolt and not
>> accept
>> >> it.
>> > I dissagree, why?
>> > a) that's only your opinion
>> > b) people did rewrite their C++ code in language far worse than C++,
>> guess
>> > which? C#. Their motivation? Much safer and easier to use. What people
>> I'm
>> > talking about? AutoDesk for example. Their flagship product, my belowed
>> > AutoCad has been rewritten in C#. Why? Why did they go to such extend?
>> Why
>> > doing something in language which is 4 to 12 times slower than C++.
>> Why!
>> > Because for everyday developer C++ as it stands is simply too difficult
>> to
>> > learn/use etc. Just think about it.
>>
>> Do you really think autodesk rewrote everything in C#, or do you think
>> they
>> just added "scriptability" support for C#? I would be astonished if they
>> rewrote
>> everything, their codebase is large. And such codebases are exactly the
>> reason
>> why we don't want to make breaking changes, there are many such large
>> codebases
>> and breaking them causes nothing but harm.
>>
>> The ease of use of languages like C# and Java is an already dispelled
>> myth.
>>
>

--




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

<br><br>On Tuesday, November 13, 2012 9:35:51 AM UTC-8, Arthur Tchaikovsky =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Do you really think autodesk rewrote everything in C#</blockquote><div>&nbs=
p;</div><div>I nowhere said everything. They definitely rewrote AutoCAD - t=
heir flagship product.&nbsp;</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
The ease of use of languages like C# and Java is an already dispelled myth<=
/blockquote><div><br></div><div>I know about it, my thesis was on this subj=
ect. The point I'm making is that people, if they convinced that the gain o=
utweights costs <i>will</i> use new language. </div><div><br></div><div>As =
for Nicol's argument of performance drop? </div><div>a) with my proposal, w=
here only uninitialized (in old code base) variables are default initialize=
d, I would be more than happy to see actual metrics and see what is this pe=
rformance drop, but, even if the performance drop would prove <i>to be </i>=
significant, it can simply be reversed (the performance drop) by supplying =
'no_init' in front of uninitialized variables. Simples.</div></blockquote><=
div><br>You seem to misunderstand how this works. C++ is C++, and maintaini=
ng existing code takes priority, all other things being equal. Therefore, i=
f you're proposing a feature, it's <i>you</i> who needs to provide "actual =
metrics". It's <i>you</i> who needs to prove that there <i>isn't</i> a sign=
ificant performance drop. You need to prove, or at least provide real-world=
 evidence in actual codebases, that this <i>won't</i> result in exactly the=
 kind of problems being stated here.<br><br>In short, the burden of proof i=
s always on the new feature, not on current behavior. The standards committ=
ee is not going to make a major change to the language like that without su=
bstantial evidence that it <i>won't</i> be exceptionally harmful. Not when =
the <i>only benefit</i> of this is added safety (important though that may =
be).<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday=
, 13 November 2012 17:29:13 UTC, Ville Voutilainen  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On 13 November 2012 19:25, Arthur Tchaikovsky &lt;<a=
>atch...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; They are not going to change their old code. And if you perfor=
m major
<br>&gt;&gt; breaking changes in a widely-used language, they will revolt a=
nd not accept
<br>&gt;&gt; it.
<br>&gt; I dissagree, why?
<br>&gt; a) that's only your opinion
<br>&gt; b) people did rewrite their C++ code in language far worse than C+=
+, guess
<br>&gt; which? C#. Their motivation? Much safer and easier to use. What pe=
ople I'm
<br>&gt; talking about? AutoDesk for example. Their flagship product, my be=
lowed
<br>&gt; AutoCad has been rewritten in C#. Why? Why did they go to such ext=
end? Why
<br>&gt; doing something in language which is 4 to 12 times slower than C++=
.. Why!
<br>&gt; Because for everyday developer C++ as it stands is simply too diff=
icult to
<br>&gt; learn/use etc. Just think about it.
<br>
<br>Do you really think autodesk rewrote everything in C#, or do you think =
they
<br>just added "scriptability" support for C#? I would be astonished if the=
y rewrote
<br>everything, their codebase is large. And such codebases are exactly the=
 reason
<br>why we don't want to make breaking changes, there are many such large c=
odebases
<br>and breaking them causes nothing but harm.
<br>
<br>The ease of use of languages like C# and Java is an already dispelled m=
yth.
<br></blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1668_28762068.1352828543248--

.

On 13 November 2012 19:35, DeadMG <wolfeinstein@gmail.com> wrote:
>> The compiler cannot detect that `archive` is going to fill in `data`. So
>> it must value-initialize `data` under your new wording, despite the fact
>> that I'm about to overwrite it. Same goes for overloading `operator>>` for
>> `pod_struct` and reading it from a stream.
> Or it could simply look in the body of archive and see that it does. For

That's assuming that the compiler sees the body. With separate compilation,
it might not.

> Secondly, I think there is little evidence that in 2012, the performance of
> initializing by default is significant. There's a difference between
> optimization and premature optimization.

Try writing to multi-megabyte arrays twice when you really want to
write only once.
You will find that the year 2012 has done little to help you.

--




.

On 13 November 2012 19:35, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> As for Nicol's argument of performance drop?
> a) with my proposal, where only uninitialized (in old code base) variables
> are default initialized, I would be more than happy to see actual metrics
> and see what is this performance drop, but, even if the performance drop
> would prove to be significant, it can simply be reversed (the performance
> drop) by supplying 'no_init' in front of uninitialized variables. Simples.

There's nothing simple about having to replace tons of code utilizing
the existing
rules to use some new no_init initialization.
It's a dauntingly hard task for large existing codebases.

--




.

------=_Part_53_23306559.1352829157134
Content-Type: text/plain; charset=ISO-8859-1

It might not see the body, but with LTCG and other such optimizations, it
almost certainly will. I would expect that if you're dealing with a
multi-megabyte array, then for one thing, I know many systems such as
Windows already zero pages even if it's not asked for (so the
implementation would not have to), and secondly, if your code is that
tight, then it should be super-easy for the compiler to show that it
doesn't need to fill it.

However, the only way to check this would be with some metrics. I know
that, originally, it was considered for C++ but dropped because tests
indicated it was too expensive, but that was a very long time ago. How
would you even go about gathering such information?

--




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

It might not see the body, but with LTCG and other such optimizations, it a=
lmost certainly will. I would expect that if you're dealing with a multi-me=
gabyte array, then for one thing, I know many systems such as Windows alrea=
dy zero pages even if it's not asked for (so the implementation would not h=
ave to), and secondly, if your code is that tight, then it should be super-=
easy for the compiler to show that it doesn't need to fill it.<div><br></di=
v><div>However, the only way to check this would be with some metrics. I kn=
ow that, originally, it was considered for C++ but dropped because tests in=
dicated it was too expensive, but that was a very long time ago. How would =
you even go about gathering such information?</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_53_23306559.1352829157134--

.

On 13 November 2012 19:52, DeadMG <wolfeinstein@gmail.com> wrote:
> However, the only way to check this would be with some metrics. I know that,
> originally, it was considered for C++ but dropped because tests indicated it
> was too expensive, but that was a very long time ago. How would you even go
> about gathering such information?

Compare the cost of

char x[LARGE_NUMBER];
and
char x[LARGE_NUMBER]{};

and

new char[LARGE_NUMBER];
and
new char[LARGE_NUMBER]{};

on multiple platforms/implementations?

--




.

On Nov 13, 2012, at 11:42 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:

> That's assuming that the compiler sees the body. With separate compilation,
> it might not.

Especially for things such as system calls, where it cannot.
>

--




.

--0015175cd1e2f5343704ce656e11
Content-Type: text/plain; charset=ISO-8859-1

On 13 November 2012 11:10, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:

> \Otherwise I simply see a Frankenstein. Powerful, but nothing else. It
> will scare people off. This isn't good direction for C++.


Do you believe C++11 is better or worse than C++03?  If C++11 is better,
could you elaborate on why this path was good for C++11 (since it
contradicts your assertion) but all of a sudden no good for the future?  If
you believe C++03 is better, could you please point out the concrete
reasons why?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 13 November 2012 11:10, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=
=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</a>&gt;=
</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

\Otherwise I simply see a Frankenstein. Powerful, but nothing else. It will=
 scare people off. This isn&#39;t good direction for C++.</blockquote><div>=
<br></div><div>Do you believe C++11 is better or worse than C++03? =A0If C+=
+11 is better, could you elaborate on why this path was good for C++11 (sin=
ce it contradicts your assertion) but all of a sudden no good for the futur=
e? =A0If you believe C++03 is better, could you please point out the concre=
te reasons why?</div>

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

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0015175cd1e2f5343704ce656e11--

.

------=_Part_44_13510415.1352836340543
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 13, 2012 11:29:17 AM UTC-8, Nevin ":-)" Liber wrote:
>
> On 13 November 2012 11:10, Arthur Tchaikovsky <atch...@gmail.com<javascript:>
> > wrote:
>
>> \Otherwise I simply see a Frankenstein. Powerful, but nothing else. It
>> will scare people off. This isn't good direction for C++.
>
>
> Do you believe C++11 is better or worse than C++03?  If C++11 is better,
> could you elaborate on why this path was good for C++11 (since it
> contradicts your assertion) but all of a sudden no good for the future?  If
> you believe C++03 is better, could you please point out the concrete
> reasons why?
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

As someone who would like to see a cleaned up C++ (but not as a new version
of the same language. As a new, equivalent language with the same features
but different syntax), I can explain it.

The progression from C++03 to C++11 is orthogonal to the idea of making C++
safer. For the most part, C++11 changes did not make the language safer.
All of the dangerous things are still there. There may be alternatives for
some of them, but they still exist. And in this case, are still the *default
* case.

--




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

<br><br>On Tuesday, November 13, 2012 11:29:17 AM UTC-8, Nevin ":-)" Liber =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 13 November 2012 11:1=
0, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"YKeeiMAEeKsJ">atch...@gmail.com</a>&gt=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

\Otherwise I simply see a Frankenstein. Powerful, but nothing else. It will=
 scare people off. This isn't good direction for C++.</blockquote><div><br>=
</div><div>Do you believe C++11 is better or worse than C++03? &nbsp;If C++=
11 is better, could you elaborate on why this path was good for C++11 (sinc=
e it contradicts your assertion) but all of a sudden no good for the future=
? &nbsp;If you believe C++03 is better, could you please point out the conc=
rete reasons why?</div>

</div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"YKeeiMAEeKsJ">ne...@eviloverl=
ord.com</a><wbr>&gt;&nbsp; (847) 691-1404<br></blockquote><div><br>As someo=
ne who would like to see a cleaned up C++ (but not as a new version of the =
same language. As a new, equivalent language with the same features but dif=
ferent syntax), I can explain it.<br><br>The progression from C++03 to C++1=
1 is orthogonal to the idea of making C++ safer. For the most part, C++11 c=
hanges did not make the language safer. All of the dangerous things are sti=
ll there. There may be alternatives for some of them, but they still exist.=
 And in this case, are still the <i>default</i> case. <br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_44_13510415.1352836340543--

.

I think that, in order to make progress, proposals along these lines
need implementation experience. We need a compiler or two to grow a
code-gen option to initialize all variables combined with some syntax
to suppress that initialization on particular variables. (A warning
plus suppression attribute might suffice. -Wuninitialized isn't quite
the right warning for this because it avoids false positives by
bailing on things like class members.) Then we need some
performance-critical codebases to start using the extension and report
back how it went. Until that happens, I wouldn't expect the committee
to accept a performance-breaking change like this. I _do_ think this
has a chance if the practical experience indicates that it doesn't
sacrifice performance or that the performance is easy to get back with
a few well-placed annotations.

Jeffrey

On Tue, Nov 13, 2012 at 2:28 AM, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> I wonder what are the opinions of other to create a rule that if I type, T
> stands for any type (built-in too):
>
> T var_name;
>
> It would mean that var_name would be implicitly initialized with default
> value for this type, so the above would be equivalent to:
>
> T var_name = T();
>
> If type doesn't have default value specified the first line could cause an
> error do to the lack of proper initializer.
>
> --
>
>
>

--




.

------=_Part_60_28693935.1352837174643
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, November 13, 2012 1:04:52 PM UTC+1, Arthur Tchaikovsky wrote:

> T var{};
>>
>
> I certainly like this workaround.
>
> The problem I tried to resolve is to avoid incidental usage of
> uninitialized variables.
>

Does initializing vars to default values actually solve that problem?
Sure, now it's 'initialized'. But was that really what the author intended?
Probably not. However, now the compiler can no longer detect that case.

--




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

On Tuesday, November 13, 2012 1:04:52 PM UTC+1, Arthur Tchaikovsky wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">T var{};<br></blockquote><div><br></div><div>I certainly like t=
his workaround.</div><div><br></div><div>The problem I tried to resolve is =
to avoid incidental usage of uninitialized variables.&nbsp;</div></blockquo=
te><div><br></div><div>Does initializing vars to default values actually so=
lve that problem?</div><div>Sure, now it's 'initialized'. But was that real=
ly what the author intended? Probably not. However, now the compiler can no=
 longer detect that case.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_60_28693935.1352837174643--

.

On Nov 13, 2012, at 2:06 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Does initializing vars to default values actually solve that problem?
> Sure, now it's 'initialized'. But was that really what the author intended? Probably not.

+1

Automatic initialization makes the code more deterministic, not safer
(and worse, can mask the problems).

--




.

------=_Part_133_12825628.1352839377361
Content-Type: text/plain; charset=ISO-8859-1

Automatic initialization won't mask a problem. If you depended on
initialization, and now it's automatic, then there is no problem.

--




------=_Part_133_12825628.1352839377361
Content-Type: text/html; charset=ISO-8859-1

Automatic initialization won't mask a problem. If you depended on initialization, and now it's automatic, then there is no problem. 

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_133_12825628.1352839377361--

.

On Tue, Nov 13, 2012 at 12:42 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> Automatic initialization won't mask a problem. If you depended on
> initialization, and now it's automatic, then there is no problem.

If you depended on initialization, and now it's automatic and *wrong*,
then there still is a problem, but it's now harder to find. Here's a
common pattern (found while a large number many of Clang's
-Wsometimes-uninitialized warnings):

double find_last_good_value(const stuff &things) {
  double d;
  for (auto x : things)
    if (looks_good(x))
      d = x.value();
  return d;
}

Returning 0.0 if the desired value isn't found is frequently *wrong*
for this pattern (it was the wrong fix for more than half of the cases
I looked at, IIRC). This kind of bug is currently easy to find,
through compiler diagnostics like -Wuninitialized and tools like
Valgrind. If you define the behavior of the above code, then correct
and incorrect code become indistinguishable, our existing tools become
useless, and we can no longer detect this bug automatically.

--




.

------=_Part_247_27635589.1352850869392
Content-Type: text/plain; charset=ISO-8859-1

Probably because your bug has nothing to do with initialization or not.
Depending on initialization-related failures to detect it is, at best, just
hopeful- for example, an identical bug involving std::string could not and
would not ever be detected, and you could never rely on it being found
through this means if you did not know the type, for example. If there is a
common pattern, then factor it out into a function?

The compiler cannot second-guess the fact that you did not deal with a
boundary condition. In the above example, you are simply fortunate that
failing to deal with it in this specific case resulted in *another* failure
which it could guess at. Relying on that fact is unworkable.

--




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

Probably because your bug has nothing to do with initialization or not. Dep=
ending on initialization-related failures to detect it is, at best, just ho=
peful- for example, an identical bug involving std::string could not and wo=
uld not ever be detected, and you could never rely on it being found throug=
h this means if you did not know the type, for example. If there is a commo=
n pattern, then factor it out into a function?<div><br></div><div>The compi=
ler cannot second-guess the fact that you did not deal with a boundary cond=
ition. In the above example, you are simply fortunate that failing to deal =
with it in this specific case resulted in <i>another</i>&nbsp;failure which=
 it could guess at. Relying on that fact is unworkable.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_247_27635589.1352850869392--

.

--0015175cd9c64b3df704ce6946ed
Content-Type: text/plain; charset=ISO-8859-1

On Nov 13, 2012, at 5:54 PM, DeadMG <wolfeinstein@gmail.com> wrote:

The compiler cannot second-guess the fact that you did not deal with a
boundary condition. In the above example, you are simply fortunate that
failing to deal with it in this specific case resulted in *another* failure
which it could guess at. Relying on that fact is unworkable.


If we had a language where you always had to be explicit about
initialization or lack thereof, no guessing would have to take place, as
specifying the wrong initialization value is a different kind of (and much
rarer) error. That language is, of course, not C++.

Even deliberately asking for default initialization doesn't always do the
right thing. For instance, I have been burned by having an atomic<bool> as
a member variable, and initializing it as b() instead of as b(false). I am
now a lot more explicit about my initializations.

--




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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>On Nov 13, 2012, at 5:54 PM, DeadM=
G &lt;<a href=3D"mailto:wolfeinstein@gmail.com">wolfeinstein@gmail.com</a>&=
gt; wrote:</div>
<div><br></div><blockquote type=3D"cite">The compiler cannot second-guess t=
he fact that you did not deal with a boundary condition. In the above examp=
le, you are simply fortunate that failing to deal with it in this specific =
case resulted in <i>another</i>=A0failure which it could guess at. Relying =
on that fact is unworkable.</blockquote>
<br><div>If we had a language where you always had to be explicit about ini=
tialization or lack thereof, no guessing would have to take place, as speci=
fying the wrong initialization value is a different kind of (and much rarer=
) error. That language is, of course, not C++.=A0</div>
<div><br></div><div>Even deliberately asking for default initialization doe=
sn&#39;t always do the right thing. For instance, I have been burned by hav=
ing an atomic&lt;bool&gt; as a member variable, and initializing it as b() =
instead of as b(false). I am now a lot more explicit about my initializatio=
ns.=A0</div>
</body></html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0015175cd9c64b3df704ce6946ed--

.

On Tue, Nov 13, 2012 at 3:54 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> Probably because your bug has nothing to do with initialization or not.
> Depending on initialization-related failures to detect it is, at best, just
> hopeful- for example, an identical bug involving std::string could not and
> would not ever be detected, and you could never rely on it being found
> through this means if you did not know the type, for example. If there is a
> common pattern, then factor it out into a function?

I don't agree that the bug has nothing to do with initialization (the
bug is that the initializer was forgotten, possibly because the
boundary condition was forgotten, possibly not), but that's not really
relevant. The suggested change takes a certain class of bug, which we
currently have good tools for handling, and makes those bugs harder to
find. That has to be factored into any decision about changing the
behavior.

--




.