Back in the day, the C decision to not initialize variables implicitly
made sense.  Processors were slow, and optimizers weren't able to
identify and remove redundant assignments.  These days however it's a
source of bugs, and we have tools like placement new to delay
initialization until the moment it is needed.

I propose to reverse this, and zero-initialize scalars in functions and
structs.  For the cases where there is a performance impact, introduce a
value std::uninitialized of type std::uninitialized_t, and define
initialization of a scalar type from an std::uninitialized_t as the
current behavior.


So:


struct X {

   int a; // zeroed during construction of X

   int y = std::uninitialized; // not initialized

   int z{std::uninitialized}; // same

   int* v = new int[8]; // initialized

   int* w = new int[8](std::uninitialized); // not initialized

   std::vector<int> v{8, std::uninitialized}; // uninitialized vector!

};


There would be no effect on user-defined types, but of course they're
free to provide constructor overloads using std::uninitialized_t:


class Y {

     int _v;  // will be initialized;

public:

     Y() {}  // _v = 0

     Y(int v) : _v(v) {} // _v = v

     Y(std::uninitialized_t) : _v(std::uninitialized) {} // _v unspecified

};


I think with modern compilers the performance impact is trivial (and
nonexistent for many codes).  It's true that compilers can warn about
this, but users can ignore warnings or forget to enable them.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e320d778-1fe3-8758-6561-5606dddbd541%40scylladb.com.

.

On 5 January 2017 at 10:33, Avi Kivity <avi@scylladb.com> wrote:
> Back in the day, the C decision to not initialize variables implicitly made
> sense.  Processors were slow, and optimizers weren't able to identify and
> remove redundant assignments.  These days however it's a source of bugs, and
> we have tools like placement new to delay initialization until the moment it
> is needed.
>
> I propose to reverse this, and zero-initialize scalars in functions and


This idea has been floated before, and gets flat-out rejected due to
the breakage it would introduce.

At least one previous thread is here
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/eD78u8jDaCA/TprA-kjcAfwJ

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ_zz8LNgNLBG5hKpNN%3DaORZMgM0D56DSXD6%3DYKDGt5YQ%40mail.gmail.com.

.

--001a1145b1be3a4805054554e932
Content-Type: text/plain; charset=UTF-8

Please, no. This would dramatically harm the performance of tremendous
amounts of existing code for no good reason. Compiler warnings exist to
prevent use of uninitialised variables.

I would seriously consider stopping using the language if something so
flagrantly breaking and in violation of 'don't pay for what you don't use'
was accepted into it. Thankfully, I'm sure it won't.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGnw%3D%3Dm4%3DO%3DTYb0Oj_w1MUWybnM8pD3-twjsP0S%3Dwnypg%40mail.gmail.com.

--001a1145b1be3a4805054554e932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Please, no. This would dramatically harm the performa=
nce of tremendous amounts of existing code for no good reason. Compiler war=
nings exist to prevent use of uninitialised variables.<br><br></div>I would=
 seriously consider stopping using the language if something so flagrantly =
breaking and in violation of &#39;don&#39;t pay for what you don&#39;t use&=
#39; was accepted into it. Thankfully, I&#39;m sure it won&#39;t.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGnw%3D%3Dm4%3DO%3DTYb0Oj_w1MUW=
ybnM8pD3-twjsP0S%3Dwnypg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwh=
Gnw%3D%3Dm4%3DO%3DTYb0Oj_w1MUWybnM8pD3-twjsP0S%3Dwnypg%40mail.gmail.com</a>=
..<br />

--001a1145b1be3a4805054554e932--

.

On 05.01.2017 09:43, Ville Voutilainen wrote:
> This idea has been floated before, and gets flat-out rejected due to
> the breakage it would introduce.
>

What breakage?
Isn't it undefined behavior to use an uninitialized variable?
So changing it to 0 initialization would only make undefined behavior
defined, bot no one should depend on an uninitialized value anyway.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/875f60fe-18ff-a276-c409-ad6c95450597%40gmail.com.

.

On 01/05/2017 10:44 AM, D. B. wrote:
> Please, no. This would dramatically harm the performance of tremendous
> amounts of existing code for no good reason. Compiler warnings exist
> to prevent use of uninitialised variables.
>

I understand the issue with existing code, but compiler warnings are not
a solution.  They are often not able to distinguish between validly
uninitialized variables and the problematic cases.

> I would seriously consider stopping using the language if something so
> flagrantly breaking and in violation of 'don't pay for what you don't
> use' was accepted into it.

The proposal does not violate the principle.  If you want your variable
to be uninitialized, you can explicitly say so.  It just switches the
default to something safer.


> Thankfully, I'm sure it won't.
>


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/82155469-473f-9a3c-5843-3844d8a490e4%40scylladb.com.

.

--047d7b86e2f8035a290545565bdd
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity <avi@scylladb.com> wrote:

>
>
> On 01/05/2017 10:44 AM, D. B. wrote:
>
>> Please, no. This would dramatically harm the performance of tremendous
>> amounts of existing code for no good reason. Compiler warnings exist to
>> prevent use of uninitialised variables.
>>
>>
> I understand the issue with existing code, but compiler warnings are not a
> solution.  They are often not able to distinguish between validly
> uninitialized variables and the problematic cases.
>

Don't have have attribute [[uninitialized]] for that?

Also, if the problem is really QoI, then fix the implementation.



> I would seriously consider stopping using the language if something so
>> flagrantly breaking and in violation of 'don't pay for what you don't use'
>> was accepted into it.
>>
>
> The proposal does not violate the principle.  If you want your variable to
> be uninitialized, you can explicitly say so.  It just switches the default
> to something safer.
>

Right, so if I don't want to pay in pointless slowdown, I have to pay in
pointlessly verbose code. Great!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhH5270iZetDUi%2B2B5aFU65U2wzx6CgYYCosUnH_3gmb3A%40mail.gmail.com.

--047d7b86e2f8035a290545565bdd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 10:26 AM, Avi Kivity <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:avi@scylladb.com" target=3D"_blank">avi@scylladb.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
<br>
On 01/05/2017 10:44 AM, D. B. wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Please, no. This would dramatically harm the performance of tremendous amou=
nts of existing code for no good reason. Compiler warnings exist to prevent=
 use of uninitialised variables.<br>
<br>
</blockquote>
<br></span>
I understand the issue with existing code, but compiler warnings are not a =
solution.=C2=A0 They are often not able to distinguish between validly unin=
itialized variables and the problematic cases.<span class=3D""><br></span><=
/blockquote><div><br></div><div>Don&#39;t have have attribute [[uninitializ=
ed]] for that?<br><br></div><div>Also, if the problem is really QoI, then f=
ix the implementation.<br></div><div><br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span class=3D"">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I would seriously consider stopping using the language if something so flag=
rantly breaking and in violation of &#39;don&#39;t pay for what you don&#39=
;t use&#39; was accepted into it.<br>
</blockquote>
<br></span>
The proposal does not violate the principle.=C2=A0 If you want your variabl=
e to be uninitialized, you can explicitly say so.=C2=A0 It just switches th=
e default to something safer.<span class=3D""></span><br></blockquote></div=
><br></div><div class=3D"gmail_extra">Right, so if I don&#39;t want to pay =
in pointless slowdown, I have to pay in pointlessly verbose code. Great!<br=
><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhH5270iZetDUi%2B2B5aFU65U2wzx6C=
gYYCosUnH_3gmb3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhH5270iZe=
tDUi%2B2B5aFU65U2wzx6CgYYCosUnH_3gmb3A%40mail.gmail.com</a>.<br />

--047d7b86e2f8035a290545565bdd--

.

On 05.01.2017 11:27, D. B. wrote:
> On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>> wrote:

> Right, so if I don't want to pay in pointless slowdown, I have to pay in
> pointlessly verbose code. Great!

What's your problem?

You initialize your variables at some point, right?

And every compiler is able to optimize `a = 0; a = 3` to `a = 3`, so
where's the pointless slow down?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b90698ca-2701-385d-32ad-2318278e8270%40gmail.com.

.

This is a multi-part message in MIME format.
--------------F1992FE304E23B5A11CA87BB
Content-Type: text/plain; charset=UTF-8; format=flowed



On 01/05/2017 12:27 PM, D. B. wrote:
> On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>> wrote:
>
>
>
>     On 01/05/2017 10:44 AM, D. B. wrote:
>
>         Please, no. This would dramatically harm the performance of
>         tremendous amounts of existing code for no good reason.
>         Compiler warnings exist to prevent use of uninitialised variables.
>
>
>     I understand the issue with existing code, but compiler warnings
>     are not a solution.  They are often not able to distinguish
>     between validly uninitialized variables and the problematic cases.
>
>
> Don't have have attribute [[uninitialized]] for that?
>
> Also, if the problem is really QoI, then fix the implementation.
>

I don't think it's so easy.

class X {
     int _i;
public:
     X();
     void foo(); // uses _i
};

If X::X() and X::foo() are in different translation units, the compiler
cannot detect the misuse of the uninitialized _t.


>         I would seriously consider stopping using the language if
>         something so flagrantly breaking and in violation of 'don't
>         pay for what you don't use' was accepted into it.
>
>
>     The proposal does not violate the principle.  If you want your
>     variable to be uninitialized, you can explicitly say so.  It just
>     switches the default to something safer.
>
>
> Right, so if I don't want to pay in pointless slowdown, I have to pay
> in pointlessly verbose code. Great!
>

The majority of the code that I see initializes variables one way or
another.  The verbose code is not pointless, it tells the reader as well
as the compiler that something out of the ordinary is going on.  Plus
you get to debug fewer pointless bugs. Win!


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bbec0b4c-dbde-a229-38cc-89f6ae747376%40scylladb.com.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><br>
    </p>
    <br>
    <div class=3D"moz-cite-prefix">On 01/05/2017 12:27 PM, D. B. wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CACGiwhH5270iZetDUi+2B5aFU65U2wzx6CgYYCosUnH_3gmb3A@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Thu, Jan 5, 2017 at 10:26 AM, Avi
            Kivity <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scyl=
ladb.com</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D""><br>
                <br>
                On 01/05/2017 10:44 AM, D. B. wrote:<br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Please, no. This would dramatically harm the
                  performance of tremendous amounts of existing code for
                  no good reason. Compiler warnings exist to prevent use
                  of uninitialised variables.<br>
                  <br>
                </blockquote>
                <br>
              </span>
              I understand the issue with existing code, but compiler
              warnings are not a solution.=C2=A0 They are often not able to
              distinguish between validly uninitialized variables and
              the problematic cases.<span class=3D""><br>
              </span></blockquote>
            <div><br>
            </div>
            <div>Don't have have attribute [[uninitialized]] for that?<br>
              <br>
            </div>
            <div>Also, if the problem is really QoI, then fix the
              implementation.<br>
            </div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I don't think it's so easy.<br>
    <br>
    class X {<br>
    =C2=A0=C2=A0=C2=A0 int _i;<br>
    public:<br>
    =C2=A0=C2=A0=C2=A0 X();<br>
    =C2=A0=C2=A0=C2=A0 void foo(); // uses _i<br>
    };<br>
    <br>
    If X::X() and X::foo() are in different translation units, the
    compiler cannot detect the misuse of the uninitialized _t.<br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CACGiwhH5270iZetDUi+2B5aFU65U2wzx6CgYYCosUnH_3gmb3A@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D"">
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  I would seriously consider stopping using the language
                  if something so flagrantly breaking and in violation
                  of 'don't pay for what you don't use' was accepted
                  into it.<br>
                </blockquote>
                <br>
              </span>
              The proposal does not violate the principle.=C2=A0 If you wan=
t
              your variable to be uninitialized, you can explicitly say
              so.=C2=A0 It just switches the default to something safer.<sp=
an
                class=3D""></span><br>
            </blockquote>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">Right, so if I don't want to pay in
          pointless slowdown, I have to pay in pointlessly verbose code.
          Great!<br>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    The majority of the code that I see initializes variables one way or
    another.=C2=A0 The verbose code is not pointless, it tells the reader a=
s
    well as the compiler that something out of the ordinary is going
    on.=C2=A0 Plus you get to debug fewer pointless bugs. Win!<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bbec0b4c-dbde-a229-38cc-89f6ae747376%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/bbec0b4c-dbde-a229-38cc-89f6ae7473=
76%40scylladb.com</a>.<br />

--------------F1992FE304E23B5A11CA87BB--

.

--94eb2c074a04a1b1030545568090
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 5, 2017 at 10:32 AM, Jonathan M=C3=BCller <
jonathanmueller.dev@gmail.com> wrote:

> On 05.01.2017 11:27, D. B. wrote:
>
>> On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity <avi@scylladb.com
>> <mailto:avi@scylladb.com>> wrote:
>>
>
> Right, so if I don't want to pay in pointless slowdown, I have to pay in
>> pointlessly verbose code. Great!
>>
>
> What's your problem?
>

People deciding they know better than me what my code represents?


You initialize your variables at some point, right?
>

Yes, but if I have e.g. a large array of structs, some of whose members
can't be set on construction but have to be assigned later, then being
required to default-initialise them redundantly upon construction would be
a useless burden on performance.


And every compiler is able to optimize `a =3D 0; a =3D 3` to `a =3D 3`, so
> where's the pointless slow down?
>

I don't see how this unrealistically trivial example is relevant to any *re=
al
*objections about this proposal.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CACGiwhFYN_mD3F2XSEhWJaKRM9G_ZAqxqCnWG0JXMLwKbBy=
f8A%40mail.gmail.com.

--94eb2c074a04a1b1030545568090
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 10:32 AM, Jonathan M=C3=BCller <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jonathanmueller.dev@gmail.com" target=3D"_blank">jonathanmue=
ller.dev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">On 05.01.2017 11:27, D. B. wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity &lt;<a href=3D"mailto:avi@scyll=
adb.com" target=3D"_blank">avi@scylladb.com</a><br></span>
&lt;mailto:<a href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylla=
db.com</a>&gt;&gt; wrote:<br>
</blockquote><span class=3D"">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Right, so if I don&#39;t want to pay in pointless slowdown, I have to pay i=
n<br>
pointlessly verbose code. Great!<br>
</blockquote>
<br></span>
What&#39;s your problem?<br></blockquote><div><br></div><div>People decidin=
g they know better than me what my code represents?<br></div><div>=C2=A0<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
You initialize your variables at some point, right?<br></blockquote><div><b=
r></div><div>Yes, but if I have e.g. a large array of structs, some of whos=
e members can&#39;t be set on construction but have to be assigned later, t=
hen being required to default-initialise them redundantly upon construction=
 would be a useless burden on performance.<br></div><div>=C2=A0<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
And every compiler is able to optimize `a =3D 0; a =3D 3` to `a =3D 3`, so =
where&#39;s the pointless slow down?<span class=3D""><br></span></blockquot=
e><div><br></div><div>I don&#39;t see how this unrealistically trivial exam=
ple is relevant to any <i>real </i>objections about this proposal.<br><br><=
/div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFYN_mD3F2XSEhWJaKRM9G_ZAqxqCnW=
G0JXMLwKbByf8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFYN_mD3F2X=
SEhWJaKRM9G_ZAqxqCnWG0JXMLwKbByf8A%40mail.gmail.com</a>.<br />

--94eb2c074a04a1b1030545568090--

.

On 5 January 2017 at 10:45, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On 05.01.2017 09:43, Ville Voutilainen wrote:
>>
>> This idea has been floated before, and gets flat-out rejected due to
>> the breakage it would introduce.
>>
>
> What breakage?

Detrimental performance changes in existing valid code.

> Isn't it undefined behavior to use an uninitialized variable?

Sure, but said existing code doesn't do that.

> So changing it to 0 initialization would only make undefined behavior
> defined, bot no one should depend on an uninitialized value anyway.


It will also write to certain memory locations twice, when existing
code writes to them only once.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYqMw-i3SgVNNDymeQZ-YEmHQeVpX9dd5vw6iJHeHf=
YZg%40mail.gmail.com.

.

On 5 January 2017 at 12:27, D. B. <db0451@gmail.com> wrote:
>> I understand the issue with existing code, but compiler warnings are not a
>> solution.  They are often not able to distinguish between validly
>> uninitialized variables and the problematic cases.
>
>
> Don't have have attribute [[uninitialized]] for that?

No, we don't. Such an attribute has been envisioned in previous
discussions about this matter,
but never went further than that afaics.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY4VvVxO6W8fs%3DPUg5pin22%2BtiaS57harvHnTWi%3Ddu%2B%2BA%40mail.gmail.com.

.

On 05.01.2017 11:38, D. B. wrote:
> On Thu, Jan 5, 2017 at 10:32 AM, Jonathan M=C3=BCller
> <jonathanmueller.dev@gmail.com <mailto:jonathanmueller.dev@gmail.com>>
> wrote:
>
>     On 05.01.2017 11:27, D. B. wrote:
>
>         On Thu, Jan 5, 2017 at 10:26 AM, Avi Kivity <avi@scylladb.com
>         <mailto:avi@scylladb.com>
>         <mailto:avi@scylladb.com <mailto:avi@scylladb.com>>> wrote:
>
>
>         Right, so if I don't want to pay in pointless slowdown, I have
>         to pay in
>         pointlessly verbose code. Great!
>
>
>     What's your problem?
>
>
> People deciding they know better than me what my code represents?

I am only talking about the pointless slow down.

>
>
>     You initialize your variables at some point, right?
>
>
> Yes, but if I have e.g. a large array of structs, some of whose members
> can't be set on construction but have to be assigned later, then being
> required to default-initialise them redundantly upon construction would
> be a useless burden on performance.
>
>
>     And every compiler is able to optimize `a =3D 0; a =3D 3` to `a =3D 3=
`, so
>     where's the pointless slow down?
>
>
> I don't see how this unrealistically trivial example is relevant to any
> /real /objections about this proposal.

This wasn't meant as an example, this was just meant as a description of=20
the optimization. Read it as "Every compiler is able to optimize=20
redundant writes".

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3870bc78-3ce6-1825-4558-cdfbb8241fcc%40gmail.com=
..

.

On 05.01.2017 11:46, Ville Voutilainen wrote:

>> Don't have have attribute [[uninitialized]] for that?
>
> No, we don't. Such an attribute has been envisioned in previous
> discussions about this matter,
> but never went further than that afaics.
>

Why? I think it's a good idea. Gives the reader and the compiler more
information about the meaning of code.

It would allow compiler warnings about uninitialized variables not
marked with it, so one day variables that are not uninitialized and not
marked *might* be zero initialized automatically.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6566f535-f7a1-18e9-27e4-f6f2ec78a860%40gmail.com.

.

On 5 January 2017 at 12:49, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> This wasn't meant as an example, this was just meant as a description of =
the
> optimization. Read it as "Every compiler is able to optimize redundant
> writes".


Maybe, but few compilers are able to optimize redundant writes in
separate translation units.
And there's plenty of code out there where the creation of a buffer
and writing to it are
in separate translation units.

In order to make the proposed change, come back with proof that it
doesn't hurt performance anywhere.
Before that, it will not fly anywhere.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbJkv1SsGxFdDghX0ywVrw4GRzC34ty3CytWW4NG4k=
A1A%40mail.gmail.com.

.

On 05.01.2017 11:58, Ville Voutilainen wrote:
> On 5 January 2017 at 12:49, Jonathan M=C3=BCller
> <jonathanmueller.dev@gmail.com> wrote:
>> This wasn't meant as an example, this was just meant as a description of=
 the
>> optimization. Read it as "Every compiler is able to optimize redundant
>> writes".
>
>
> Maybe, but few compilers are able to optimize redundant writes in
> separate translation units.
> And there's plenty of code out there where the creation of a buffer
> and writing to it are
> in separate translation units.

Yeah, I've realized that as well.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e983ef9d-46c9-1006-ffa2-3fcfbf75af9e%40gmail.com=
..

.

On 5 January 2017 at 12:58, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On 05.01.2017 11:46, Ville Voutilainen wrote:
>
>>> Don't have have attribute [[uninitialized]] for that?
>>
>>
>> No, we don't. Such an attribute has been envisioned in previous
>> discussions about this matter,
>> but never went further than that afaics.
>>
>
> Why? I think it's a good idea. Gives the reader and the compiler more
> information about the meaning of code.

Because nobody bothered to write a proposal.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYa-2Ac%3D9BnbW-Tc_SxTVQjEzao1f%3DxPvgze6B=
ZmSAnRw%40mail.gmail.com.

.

On 05.01.2017 11:59, Ville Voutilainen wrote:
>
> Because nobody bothered to write a proposal.
>

I can volunteer, what do I have to do?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b439e0e-9fd5-aac5-3893-c07b32b98ad8%40gmail.com.

.

On 5 January 2017 at 13:00, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On 05.01.2017 11:59, Ville Voutilainen wrote:
>>
>>
>> Because nobody bothered to write a proposal.
>>
>
> I can volunteer, what do I have to do?


Read this: http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0068r0.pdf
and its wording papers,
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0188r1.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0189r1.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0212r1.pdf

Find a champion who can agree to present such a proposal, then write
something similar
to those and send it to me with the information about the champion.
Note that you don't
need to use pdf, html is fine, and in fact better. I have found this
paper to provide a very
good basis: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3325.h=
tml

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUb22vfk%2BR2X4zPB6dW9fM13bfpYHTCw5fHTKzKme=
QgoOg%40mail.gmail.com.

.

On 05.01.2017 12:05, Ville Voutilainen wrote:
> On 5 January 2017 at 13:00, Jonathan M=C3=BCller
> <jonathanmueller.dev@gmail.com> wrote:
>> On 05.01.2017 11:59, Ville Voutilainen wrote:
>>>
>>>
>>> Because nobody bothered to write a proposal.
>>>
>>
>> I can volunteer, what do I have to do?
>
>
> Read this: http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0068r0.pd=
f
> and its wording papers,
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0188r1.pdf
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0189r1.pdf
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0212r1.pdf
>
> Find a champion who can agree to present such a proposal, then write
> something similar
> to those and send it to me with the information about the champion.
> Note that you don't
> need to use pdf, html is fine, and in fact better. I have found this
> paper to provide a very
> good basis: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3325=
..html
>

Thanks a lot, I'll get back to you.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f26eae19-0159-886f-ba03-fa223afebaae%40gmail.com=
..

.

Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutilai=
nen=20
escreveu:
> In order to make the proposed change, come back with proof that it
> doesn't hurt performance anywhere.
> Before that, it will not fly anywhere.

Think especially of non-static data members. Given NSDMI, your proposal=20
automatically means all member variables are zero-initialised unless=20
explicitly initialised ith std::uninitialised in the constructor. This is a=
=20
perfect example of what Ville is saying: the compiler simply cannot prove t=
hat=20
a variable left uninitialised in a constructor is a good thing or not.

Changing the default means all constructors (including inline ones!) must=
=20
zero-intialise, even variables whose contents are protected by other member=
=20
variables, =C3=A0 la std::optional.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4624163.gm4MgrvsJC%40tjmaciei-mobl1.

.

On 01/05/2017 06:53 PM, Thiago Macieira wrote:
> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutil=
ainen
> escreveu:
>> In order to make the proposed change, come back with proof that it
>> doesn't hurt performance anywhere.
>> Before that, it will not fly anywhere.
> Think especially of non-static data members.

That was indeed my motivation.  Statics are already initialized, and=20
automatic storage duration variables are normally declared at the point=20
of initialization in modern code.

>   Given NSDMI, your proposal
> automatically means all member variables are zero-initialised unless
> explicitly initialised ith std::uninitialised in the constructor. This is=
 a
> perfect example of what Ville is saying: the compiler simply cannot prove=
 that
> a variable left uninitialised in a constructor is a good thing or not.
>
> Changing the default means all constructors (including inline ones!) must
> zero-intialise, even variables whose contents are protected by other memb=
er
> variables, =C3=A0 la std::optional.


No, std::optional will placement-new the variable when the optional is=20
engaged.  Similar to how reserved-but-not-initialized vector elements=20
are not initialized until they are push_back()ed.


Of course, there is a performance impact, but with modern C++ it grows=20
smaller and smaller as people use containers, or other abstractions to=20
manage their data; for example std::string or a matrix library know=20
whether they need to initialize or not.  There will be some code that is=20
negatively impacted (this can be addressed by adding std::uninitialized=20
or whatever) and some code that is positively impacted, by converting=20
heisenbugs to repeatable behavior.



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bf9fe7b0-93ea-a553-3a4a-bf15ea59b721%40scylladb.=
com.

.

On 5 January 2017 at 20:12, Avi Kivity <avi@scylladb.com> wrote:
> Of course, there is a performance impact, but with modern C++ it grows
> smaller and smaller as people use containers, or other abstractions to
> manage their data; for example std::string or a matrix library know whether
> they need to initialize or not.  There will be some code that is negatively
> impacted (this can be addressed by adding std::uninitialized or whatever)
> and some code that is positively impacted, by converting heisenbugs to
> repeatable behavior.


"Smaller and smaller" and "some" don't cut it as rationale.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaftqVa3cgycra-yyx09dfgzg1WW9xu5uMnQHjitvDEDw%40mail.gmail.com.

.

--001a113d4ed279dede05455cf066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One possible place where this could have severe negative impacts would be
write-combined memory.

Some of the vagaries of write-combined memory are discussed here:
https://fgiesen.wordpress.com/2013/01/29/write-combining-is-not-your-friend=
/

Especially note at the end how it talks about the importance of sequential
writes. If we do one pass over the data structure to zero-initialize it and
another pass over the data structure to set it to the actual values we want
then you may cause either major performance hits or even undefined behavior=
..

I've never worked with WC memory myself so I don't know how much this might
or might not be an issue, but remember that C++ might also be used in some
lower level drivers for example.

On Thu, Jan 5, 2017 at 12:12 PM, Avi Kivity <avi@scylladb.com> wrote:

> On 01/05/2017 06:53 PM, Thiago Macieira wrote:
>
>> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Vouti=
lainen
>> escreveu:
>>
>>> In order to make the proposed change, come back with proof that it
>>> doesn't hurt performance anywhere.
>>> Before that, it will not fly anywhere.
>>>
>> Think especially of non-static data members.
>>
>
> That was indeed my motivation.  Statics are already initialized, and
> automatic storage duration variables are normally declared at the point o=
f
> initialization in modern code.
>
>   Given NSDMI, your proposal
>> automatically means all member variables are zero-initialised unless
>> explicitly initialised ith std::uninitialised in the constructor. This i=
s
>> a
>> perfect example of what Ville is saying: the compiler simply cannot prov=
e
>> that
>> a variable left uninitialised in a constructor is a good thing or not.
>>
>> Changing the default means all constructors (including inline ones!) mus=
t
>> zero-intialise, even variables whose contents are protected by other
>> member
>> variables, =C3=A0 la std::optional.
>>
>
>
> No, std::optional will placement-new the variable when the optional is
> engaged.  Similar to how reserved-but-not-initialized vector elements are
> not initialized until they are push_back()ed.
>
>
> Of course, there is a performance impact, but with modern C++ it grows
> smaller and smaller as people use containers, or other abstractions to
> manage their data; for example std::string or a matrix library know wheth=
er
> they need to initialize or not.  There will be some code that is negative=
ly
> impacted (this can be addressed by adding std::uninitialized or whatever)
> and some code that is positively impacted, by converting heisenbugs to
> repeatable behavior.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/bf9fe7b0-93ea-a553-3a4a-
> bf15ea59b721%40scylladb.com.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADbh%2BeT7iCftgC9Bier%3DeY-EmrP1qEQ5PH17VkeDt28=
mXAQcXg%40mail.gmail.com.

--001a113d4ed279dede05455cf066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One possible place where this could have severe negative i=
mpacts would be write-combined memory.<div><br></div><div>Some of the vagar=
ies of write-combined memory are discussed here:</div><div><a href=3D"https=
://fgiesen.wordpress.com/2013/01/29/write-combining-is-not-your-friend/">ht=
tps://fgiesen.wordpress.com/2013/01/29/write-combining-is-not-your-friend/<=
/a><br></div><div><br></div><div>Especially note at the end how it talks ab=
out the importance of sequential writes. If we do one pass over the data st=
ructure to zero-initialize it and another pass over the data structure to s=
et it to the actual values we want then you may cause either major performa=
nce hits or even undefined behavior.</div><div><br></div><div>I&#39;ve neve=
r worked with WC memory myself so I don&#39;t know how much this might or m=
ight not be an issue, but remember that C++ might also be used in some lowe=
r level drivers for example.</div></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Thu, Jan 5, 2017 at 12:12 PM, Avi Kivity <span di=
r=3D"ltr">&lt;<a href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scy=
lladb.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On 01/05/2017 06:53 PM, Thiago Macieira wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutilai=
nen<br>
escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In order to make the proposed change, come back with proof that it<br>
doesn&#39;t hurt performance anywhere.<br>
Before that, it will not fly anywhere.<br>
</blockquote>
Think especially of non-static data members.<br>
</blockquote>
<br></span>
That was indeed my motivation.=C2=A0 Statics are already initialized, and a=
utomatic storage duration variables are normally declared at the point of i=
nitialization in modern code.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 Given NSDMI, your proposal<br>
automatically means all member variables are zero-initialised unless<br>
explicitly initialised ith std::uninitialised in the constructor. This is a=
<br>
perfect example of what Ville is saying: the compiler simply cannot prove t=
hat<br>
a variable left uninitialised in a constructor is a good thing or not.<br>
<br>
Changing the default means all constructors (including inline ones!) must<b=
r>
zero-intialise, even variables whose contents are protected by other member=
<br>
variables, =C3=A0 la std::optional.<br>
</blockquote>
<br>
<br></span>
No, std::optional will placement-new the variable when the optional is enga=
ged.=C2=A0 Similar to how reserved-but-not-initialized vector elements are =
not initialized until they are push_back()ed.<br>
<br>
<br>
Of course, there is a performance impact, but with modern C++ it grows smal=
ler and smaller as people use containers, or other abstractions to manage t=
heir data; for example std::string or a matrix library know whether they ne=
ed to initialize or not.=C2=A0 There will be some code that is negatively i=
mpacted (this can be addressed by adding std::uninitialized or whatever) an=
d some code that is positively impacted, by converting heisenbugs to repeat=
able behavior.<span class=3D""><br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf9fe7b0-93ea-a553-3a4a-bf15ea59b721%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/bf9fe7b0-93ea-a553-3a4a-<w=
br>bf15ea59b721%40scylladb.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeT7iCftgC9Bier%3DeY-EmrP1qEQ5=
PH17VkeDt28mXAQcXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeT7iC=
ftgC9Bier%3DeY-EmrP1qEQ5PH17VkeDt28mXAQcXg%40mail.gmail.com</a>.<br />

--001a113d4ed279dede05455cf066--

.

--001a11423f44d0429e05455d45fd
Content-Type: text/plain; charset=UTF-8

Depending upon another magical special type is another, if relatively
minor, thing about this that bothers me. I get that the general pattern is
somewhat unavoidable in certain cases (assuming we hate adding keywords,
c.f. std::nullptr_t, std::initializer_list), but requiring primitive types
to be aware of and overloaded on it seems especially grating. I don't have
anything except a gut feeling here, mind you.


My other objections are the fact that C++ generally tries not to
incorporate behaviour that's precisely the opposite of what C does; the
fact that I'd have to sprinkle ugly std::uninitialised_t decorations all
over some parts of my code; and the fact that not doing so would -
suddenly, when this change was made from underneath us - eat into the
performance of existing codebases that can't do instantiation and
assignment at the same time.


And for what? To make things easier for those who don't want to think about
what their code is doing? I know that's not the direct motivation, but it
seems to me that's ultimately what it serves. I especially don't buy this:

Back in the day, the C decision to not initialize variables implicitly made
> sense.  Processors were slow, and optimizers weren't able to identify and
> remove redundant assignments.  These days however [...]
>

This is said like everyone is now running desktop/notebook CPUs with so
many spare cycles, they can waste them showing off how little they have to
care about knowing whether they've initialised their own objects. Those
working on embedded or other resource-constrained systems would beg to
differ, and would at best be really quite frustrated at having to go
through all their codebases dropping std::uninitialised_t everywhere in
order to get decent performance back. And then there are those of us who *do
*have cycles to waste, but just don't want to!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFwCu6%2BXV5zQHUnRHogj56U2KLVFagddRDpiogyk4wEgg%40mail.gmail.com.

--001a11423f44d0429e05455d45fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Depending upon another magical special type=
 is another, if relatively minor, thing about this that bothers me. I get t=
hat the general pattern is somewhat unavoidable in certain cases (assuming =
we hate adding keywords, c.f. std::nullptr_t, std::initializer_list), but r=
equiring primitive types to be aware of and overloaded on it seems especial=
ly grating. I don&#39;t have anything except a gut feeling here, mind you.<=
br><br></div><br>My other objections are the fact that C++ generally tries =
not to incorporate behaviour that&#39;s precisely the opposite of what C do=
es; the fact that I&#39;d have to sprinkle ugly std::uninitialised_t decora=
tions all over some parts of my code; and the fact that not doing so would =
- suddenly, when this change was made from underneath us - eat into the per=
formance of existing codebases that can&#39;t do instantiation and assignme=
nt at the same time.<br></div><br></div><br>And for what? To make things ea=
sier for those who don&#39;t want to think about what their code is doing? =
I know that&#39;s not the direct motivation, but it seems to me that&#39;s =
ultimately what it serves. I especially don&#39;t buy this:<br><br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Back in the day, the C decision t=
o not initialize variables implicitly=20
made sense.=C2=A0 Processors were slow, and optimizers weren&#39;t able to=
=20
identify and remove redundant assignments.=C2=A0 These days however [...]<b=
r></blockquote><div><br></div><div>This is said like everyone is now runnin=
g desktop/notebook CPUs with so many spare cycles, they can waste them show=
ing off how little they have to care about knowing whether they&#39;ve init=
ialised their own objects. Those working on embedded or other resource-cons=
trained systems would beg to differ, and would at best be really quite frus=
trated at having to go through all their codebases dropping std::uninitiali=
sed_t everywhere in order to get decent performance back. And then there ar=
e those of us who <i>do </i>have cycles to waste, but just don&#39;t want t=
o!<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFwCu6%2BXV5zQHUnRHogj56U2KLVFa=
gddRDpiogyk4wEgg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFwCu6%2B=
XV5zQHUnRHogj56U2KLVFagddRDpiogyk4wEgg%40mail.gmail.com</a>.<br />

--001a11423f44d0429e05455d45fd--

.

--94eb2c063d048a04ad05455df54c
Content-Type: text/plain; charset=UTF-8

This goes against the C++'s philosophy of not paying for what you do not
use. The desired behavior would be to opt-in, not opt-out, and opting-in
doesn't make sense here.

On Thu, Jan 5, 2017 at 12:33 AM, Avi Kivity <avi@scylladb.com> wrote:

> Back in the day, the C decision to not initialize variables implicitly
> made sense.  Processors were slow, and optimizers weren't able to identify
> and remove redundant assignments.  These days however it's a source of
> bugs, and we have tools like placement new to delay initialization until
> the moment it is needed.
>
> I propose to reverse this, and zero-initialize scalars in functions and
> structs.  For the cases where there is a performance impact, introduce a
> value std::uninitialized of type std::uninitialized_t, and define
> initialization of a scalar type from an std::uninitialized_t as the current
> behavior.
>
>
> So:
>
>
> struct X {
>
>   int a; // zeroed during construction of X
>
>   int y = std::uninitialized; // not initialized
>
>   int z{std::uninitialized}; // same
>
>   int* v = new int[8]; // initialized
>
>   int* w = new int[8](std::uninitialized); // not initialized
>
>   std::vector<int> v{8, std::uninitialized}; // uninitialized vector!
>
> };
>
>
> There would be no effect on user-defined types, but of course they're free
> to provide constructor overloads using std::uninitialized_t:
>
>
> class Y {
>
>     int _v;  // will be initialized;
>
> public:
>
>     Y() {}  // _v = 0
>
>     Y(int v) : _v(v) {} // _v = v
>
>     Y(std::uninitialized_t) : _v(std::uninitialized) {} // _v unspecified
>
> };
>
>
> I think with modern compilers the performance impact is trivial (and
> nonexistent for many codes).  It's true that compilers can warn about this,
> but users can ignore warnings or forget to enable them.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/e320d778-1fe3-8758-6561-
> 5606dddbd541%40scylladb.com.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmQdeMjR6FuHKC7TyZQsOvzjDN7QQHOLp4rcygdaD8ocdvx2A%40mail.gmail.com.

--94eb2c063d048a04ad05455df54c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This goes against the C++&#39;s philosophy of not paying f=
or what you do not use. The desired behavior would be to opt-in, not opt-ou=
t, and opting-in doesn&#39;t make sense here.</div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Thu, Jan 5, 2017 at 12:33 AM, Avi Kivi=
ty <span dir=3D"ltr">&lt;<a href=3D"mailto:avi@scylladb.com" target=3D"_bla=
nk">avi@scylladb.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Back in the day, the C decision to not initialize variables implicitly ma=
de sense.=C2=A0 Processors were slow, and optimizers weren&#39;t able to id=
entify and remove redundant assignments.=C2=A0 These days however it&#39;s =
a source of bugs, and we have tools like placement new to delay initializat=
ion until the moment it is needed.<br>
<br>
I propose to reverse this, and zero-initialize scalars in functions and str=
ucts.=C2=A0 For the cases where there is a performance impact, introduce a =
value std::uninitialized of type std::uninitialized_t, and define initializ=
ation of a scalar type from an std::uninitialized_t as the current behavior=
..<br>
<br>
<br>
So:<br>
<br>
<br>
struct X {<br>
<br>
=C2=A0 int a; // zeroed during construction of X<br>
<br>
=C2=A0 int y =3D std::uninitialized; // not initialized<br>
<br>
=C2=A0 int z{std::uninitialized}; // same<br>
<br>
=C2=A0 int* v =3D new int[8]; // initialized<br>
<br>
=C2=A0 int* w =3D new int[8](std::uninitialized); // not initialized<br>
<br>
=C2=A0 std::vector&lt;int&gt; v{8, std::uninitialized}; // uninitialized ve=
ctor!<br>
<br>
};<br>
<br>
<br>
There would be no effect on user-defined types, but of course they&#39;re f=
ree to provide constructor overloads using std::uninitialized_t:<br>
<br>
<br>
class Y {<br>
<br>
=C2=A0 =C2=A0 int _v;=C2=A0 // will be initialized;<br>
<br>
public:<br>
<br>
=C2=A0 =C2=A0 Y() {}=C2=A0 // _v =3D 0<br>
<br>
=C2=A0 =C2=A0 Y(int v) : _v(v) {} // _v =3D v<br>
<br>
=C2=A0 =C2=A0 Y(std::uninitialized_t) : _v(std::uninitialized) {} // _v uns=
pecified<br>
<br>
};<br>
<br>
<br>
I think with modern compilers the performance impact is trivial (and nonexi=
stent for many codes).=C2=A0 It&#39;s true that compilers can warn about th=
is, but users can ignore warnings or forget to enable them.<span class=3D"H=
OEnZb"><font color=3D"#888888"><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e320d778-1fe3-8758-6561-5606dddbd541%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/e320d778-1fe3-8758-6561-<w=
br>5606dddbd541%40scylladb.com</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmQdeMjR6FuHKC7TyZQsOvzjDN7QQHOLp4r=
cygdaD8ocdvx2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmQdeMjR6FuHKC7=
TyZQsOvzjDN7QQHOLp4rcygdaD8ocdvx2A%40mail.gmail.com</a>.<br />

--94eb2c063d048a04ad05455df54c--

.

On 05/01/2017 09:33, Avi Kivity wrote:
> [...] decision to not initialize variables implicitly [...] These days
> however it's a source of bugs, and we have tools like placement new to
> delay initialization until the moment it is needed.
By defining the behavior, you only make it harder to find the bug, after
all an unintendedly zero initialized value is as wrong as a random
value. By making reads from uninitialized variables ub we can (and do)
have sanitizers and/or build modes that find this kind of bugs.

If the behavior is defined all tools have to assume you really meant
what you wrote, and has no chance to determine whether you wanted to
initialize to zero or just accidentally failed to properly assign proper
values.

Best
Fabio

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d773c99-b2f6-11f7-9e57-ba82965b6177%40gmx.net.

.

--001a1146fba2f6df98054561948a
Content-Type: text/plain; charset=UTF-8

On 5 January 2017 at 12:34, Fabio Fracassi <f.fracassi@gmx.net> wrote:

> On 05/01/2017 09:33, Avi Kivity wrote:
>
>> [...] decision to not initialize variables implicitly [...] These days
>> however it's a source of bugs, and we have tools like placement new to
>> delay initialization until the moment it is needed.
>>
> By defining the behavior, you only make it harder to find the bug, after
> all an unintendedly zero initialized value is as wrong as a random value.
> By making reads from uninitialized variables ub we can (and do) have
> sanitizers and/or build modes that find this kind of bugs.
>

+1. The proposed change would, in my opinion, be a bad idea even if it had
no performance impact: the code whose semantics it changes is transitioned
from "wrong and easy to automatically detect" to "wrong and hard or
impossible to automatically detect".

If the behavior is defined all tools have to assume you really meant what
> you wrote, and has no chance to determine whether you wanted to initialize
> to zero or just accidentally failed to properly assign proper values.
>
> Best
> Fabio
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/2d773c99-b2f6-11f7-9e57-
> ba82965b6177%40gmx.net.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkOJ%3DeQ47EZtj4uA-FnabVYPD6NyjRBCptLEqoYzmMsAQ%40mail.gmail.com.

--001a1146fba2f6df98054561948a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 5=
 January 2017 at 12:34, Fabio Fracassi <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:f.fracassi@gmx.net" target=3D"_blank">f.fracassi@gmx.net</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On 05/01/2017 09:33, Avi Kivity w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
[...] decision to not initialize variables implicitly [...] These days howe=
ver it&#39;s a source of bugs, and we have tools like placement new to dela=
y initialization until the moment it is needed.<br>
</blockquote>
By defining the behavior, you only make it harder to find the bug, after al=
l an unintendedly zero initialized value is as wrong as a random value. By =
making reads from uninitialized variables ub we can (and do) have sanitizer=
s and/or build modes that find this kind of bugs.<br></blockquote><div><br>=
</div><div>+1. The proposed change would, in my opinion, be a bad idea even=
 if it had no performance impact: the code whose semantics it changes is tr=
ansitioned from &quot;wrong and easy to automatically detect&quot; to &quot=
;wrong and hard or impossible to automatically detect&quot;.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
If the behavior is defined all tools have to assume you really meant what y=
ou wrote, and has no chance to determine whether you wanted to initialize t=
o zero or just accidentally failed to properly assign proper values.<br>
<br>
Best<br>
Fabio<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d773c99-b2f6-11f7-9e57-ba82965b6177%=
40gmx.net" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/2d773c99-b2f6-11f7-9e57-<wbr>ba=
82965b6177%40gmx.net</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkOJ%3DeQ47EZtj4uA-FnabVYPD6Nyj=
RBCptLEqoYzmMsAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkOJ%3DeQ=
47EZtj4uA-FnabVYPD6NyjRBCptLEqoYzmMsAQ%40mail.gmail.com</a>.<br />

--001a1146fba2f6df98054561948a--

.

------=_Part_351_1781699959.1483664079914
Content-Type: multipart/alternative;
 boundary="----=_Part_352_63040332.1483664079915"

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

On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote:
>
> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutil=
ainen=20
> escreveu:=20
> > In order to make the proposed change, come back with proof that it=20
> > doesn't hurt performance anywhere.=20
> > Before that, it will not fly anywhere.=20
>
> Think especially of non-static data members. Given NSDMI, your proposal=
=20
> automatically means all member variables are zero-initialised unless=20
> explicitly initialised ith std::uninitialised in the constructor. This is=
=20
> a=20
> perfect example of what Ville is saying: the compiler simply cannot prove=
=20
> that=20
> a variable left uninitialised in a constructor is a good thing or not.=20
>
> Changing the default means all constructors (including inline ones!) must=
=20
> zero-intialise, even variables whose contents are protected by other=20
> member=20
> variables, =C3=A0 la std::optional.
>

In fact, wouldn't standardizing "zero by default" mean that no constructor=
=20
could ever be trivial, unless it was the constructor of an empty class?
(And if you additionally propose to initialize padding bytes to zero, then=
=20
you can get rid of even that special case! ;))

I think this is a great proposal... *for an optimization level*.
It seems to be in the spirit of -fwrapv / -ftrapv / -fno-strict-aliasing /=
=20
-Odebug. You have some C++ code whose behavior you *believe* to be defined=
=20
(or else you wouldn't be compiling it), and you just want to change the *pa=
rticular=20
machine instructions* emitted by the compiler for this code =E2=80=94 such =
that the=20
code will get slower, but the heap will look nicer in the debugger.  This=
=20
is a perfectly valid optimization tradeoff, and I encourage vendors to go=
=20
out and implement it as an option; but IMO it has nothing to do with the *l=
anguage-level=20
semantics* of C++.

Likewise I'm in favor of a "friendly C" mode where bit-shifts DTRT by=20
default, and signed overflow is defined a la -fwrapv, and so on... but I=20
would never ever propose that such a mode be standardized in any way,=20
because it simply has nothing to do with the semantics of the language.=20
It's just an optimization level "below -O0", that's all.

See John Regehr's informal proposal and informal retraction of "friendly C"=
=20
a year or two ago: http://blog.regehr.org/archives/1180=20
http://blog.regehr.org/archives/1287

HTH,
Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/561f0f9d-762a-4b7c-ab46-131afa6bf44e%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em quinta-feira,=
 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutilainen=20
<br>escreveu:
<br>&gt; In order to make the proposed change, come back with proof that it
<br>&gt; doesn&#39;t hurt performance anywhere.
<br>&gt; Before that, it will not fly anywhere.
<br>
<br>Think especially of non-static data members. Given NSDMI, your proposal=
=20
<br>automatically means all member variables are zero-initialised unless=20
<br>explicitly initialised ith std::uninitialised in the constructor. This =
is a=20
<br>perfect example of what Ville is saying: the compiler simply cannot pro=
ve that=20
<br>a variable left uninitialised in a constructor is a good thing or not.
<br>
<br>Changing the default means all constructors (including inline ones!) mu=
st=20
<br>zero-intialise, even variables whose contents are protected by other me=
mber=20
<br>variables, =C3=A0 la std::optional.<br></blockquote><div><br></div><div=
>In fact, wouldn&#39;t standardizing &quot;zero by default&quot; mean that =
no constructor could ever be trivial, unless it was the constructor of an e=
mpty class?</div><div>(And if you additionally propose to initialize paddin=
g bytes to zero, then you can get rid of even that special case! ;))</div><=
div><br></div><div>I think this is a great proposal... <i>for an optimizati=
on level</i>.</div><div>It seems to be in the spirit of -fwrapv / -ftrapv /=
 -fno-strict-aliasing / -Odebug. You have some C++ code whose behavior you =
<i>believe</i> to be defined (or else you wouldn&#39;t be compiling it), an=
d you just want to change the <i>particular machine instructions</i> emitte=
d by the compiler for this code =E2=80=94 such that the code will get slowe=
r, but the heap will look nicer in the debugger. =C2=A0This is a perfectly =
valid optimization tradeoff, and I encourage vendors to go out and implemen=
t it as an option; but IMO it has nothing to do with the <i>language-level =
semantics</i>=C2=A0of C++.</div><div><br></div><div>Likewise I&#39;m in fav=
or of a &quot;friendly C&quot; mode where bit-shifts DTRT by default, and s=
igned overflow is defined a la -fwrapv, and so on... but I would never ever=
 propose that such a mode be standardized in any way, because it simply has=
 nothing to do with the semantics of the language. It&#39;s just an optimiz=
ation level &quot;below -O0&quot;, that&#39;s all.</div><div><br></div><div=
>See John Regehr&#39;s informal proposal and informal retraction of &quot;f=
riendly C&quot; a year or two ago: <a href=3D"http://blog.regehr.org/archiv=
es/1180">http://blog.regehr.org/archives/1180</a>=C2=A0<a href=3D"http://bl=
og.regehr.org/archives/1287">http://blog.regehr.org/archives/1287</a></div>=
<div><br></div><div>HTH,</div><div>Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/561f0f9d-762a-4b7c-ab46-131afa6bf44e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/561f0f9d-762a-4b7c-ab46-131afa6bf44e=
%40isocpp.org</a>.<br />

------=_Part_352_63040332.1483664079915--

------=_Part_351_1781699959.1483664079914--

.

------=_Part_72_696034775.1483666288818
Content-Type: multipart/alternative;
 boundary="----=_Part_73_826068159.1483666288818"

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

On Thursday, January 5, 2017 at 7:54:40 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote:
>>
>> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Vouti=
lainen=20
>> escreveu:=20
>> > In order to make the proposed change, come back with proof that it=20
>> > doesn't hurt performance anywhere.=20
>> > Before that, it will not fly anywhere.=20
>>
>> Think especially of non-static data members. Given NSDMI, your proposal=
=20
>> automatically means all member variables are zero-initialised unless=20
>> explicitly initialised ith std::uninitialised in the constructor. This i=
s=20
>> a=20
>> perfect example of what Ville is saying: the compiler simply cannot prov=
e=20
>> that=20
>> a variable left uninitialised in a constructor is a good thing or not.=
=20
>>
>> Changing the default means all constructors (including inline ones!) mus=
t=20
>> zero-intialise, even variables whose contents are protected by other=20
>> member=20
>> variables, =C3=A0 la std::optional.
>>
>
> In fact, wouldn't standardizing "zero by default" mean that no constructo=
r=20
> could ever be trivial, unless it was the constructor of an empty class?
>

Technically, no. Zero-initialization of a trivial type should be handled by=
=20
the code performing the initialization, rather than the type's constructor.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c37e0bba-5b06-4aba-a84d-6ba0a6f2efd2%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 7:54:40 PM UTC-5, Arthur O=
&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Em quinta-feira, 5 de janeiro de 2=
017, =C3=A0s 12:58:58 PST, Ville Voutilainen=20
<br>escreveu:
<br>&gt; In order to make the proposed change, come back with proof that it
<br>&gt; doesn&#39;t hurt performance anywhere.
<br>&gt; Before that, it will not fly anywhere.
<br>
<br>Think especially of non-static data members. Given NSDMI, your proposal=
=20
<br>automatically means all member variables are zero-initialised unless=20
<br>explicitly initialised ith std::uninitialised in the constructor. This =
is a=20
<br>perfect example of what Ville is saying: the compiler simply cannot pro=
ve that=20
<br>a variable left uninitialised in a constructor is a good thing or not.
<br>
<br>Changing the default means all constructors (including inline ones!) mu=
st=20
<br>zero-intialise, even variables whose contents are protected by other me=
mber=20
<br>variables, =C3=A0 la std::optional.<br></blockquote><div><br></div><div=
>In fact, wouldn&#39;t standardizing &quot;zero by default&quot; mean that =
no constructor could ever be trivial, unless it was the constructor of an e=
mpty class?</div></div></blockquote><div><br>Technically, no. Zero-initiali=
zation of a trivial type should be handled by the code performing the initi=
alization, rather than the type&#39;s constructor.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c37e0bba-5b06-4aba-a84d-6ba0a6f2efd2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c37e0bba-5b06-4aba-a84d-6ba0a6f2efd2=
%40isocpp.org</a>.<br />

------=_Part_73_826068159.1483666288818--

------=_Part_72_696034775.1483666288818--

.

--001a114a0104e0f7a3054563beea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 5, 2017 at 5:31 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, January 5, 2017 at 7:54:40 PM UTC-5, Arthur O'Dwyer wrote:
>>
>> On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote:
>>>
>>>
>>> Changing the default means all constructors (including inline ones!)
>>> must
>>> zero-intialise, even variables whose contents are protected by other
>>> member
>>> variables, =C3=A0 la std::optional.
>>>
>>
>> In fact, wouldn't standardizing "zero by default" mean that no
>> constructor could ever be trivial, unless it was the constructor of an
>> empty class?
>>
>
> Technically, no. Zero-initialization of a trivial type should be handled
> by the code performing the initialization, rather than the type's
> constructor.
>

Yeah, I should have worded that differently. I meant that in C++ today,
there is a very convenient equivalence between
is_trivial_according_to_the_standard(func) and
has_no_observable_effect_on_the_machine(func).  If we were to change the
language semantics so that for some "func"s, such as S::S() here =E2=80=94

    struct S { int i; S() =3D default; };

=E2=80=94 we had is_trivial_according_to_the_standard(func) and yet
must_produce_an_observable_effect(func), we'd lose this convenient
equivalence, at which point I'd question the utility of the notion of
"trivial function" at all.

Of course this is all completely hypothetical and counterfactual. I don't
mean to suggest that this zero-initialization idea has a snowball's chance
of getting in front of the committee. Just engaging in some
proof-by-contradiction here. :)

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0KZ088Fon-LwN4wBdNjjJi0tnXHBjtsLB7faQ5qRfV=
Fug%40mail.gmail.com.

--001a114a0104e0f7a3054563beea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jan 5, 2017 at 5:31 PM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On T=
hursday, January 5, 2017 at 7:54:40 PM UTC-5, Arthur O&#39;Dwyer wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Thursday, January 5, 2017 at 9:49:20 AM UT=
C-8, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><br>Changing the default means =
all constructors (including inline ones!) must=20
<br>zero-intialise, even variables whose contents are protected by other me=
mber=20
<br>variables, =C3=A0 la std::optional.<br></blockquote><div><br></div><div=
>In fact, wouldn&#39;t standardizing &quot;zero by default&quot; mean that =
no constructor could ever be trivial, unless it was the constructor of an e=
mpty class?</div></div></blockquote></span><div><br>Technically, no. Zero-i=
nitialization of a trivial type should be handled by the code performing th=
e initialization, rather than the type&#39;s constructor.<br></div></div></=
blockquote><div><br></div><div>Yeah, I should have worded that differently.=
 I meant that in C++ today, there is a very convenient equivalence between =
is_trivial_according_to_the_standard(func) and has_no_observable_effect_on_=
the_machine(func).=C2=A0 If we were to change the language semantics so tha=
t for some &quot;func&quot;s, such as S::S() here =E2=80=94</div><div><br><=
/div><div>=C2=A0 =C2=A0 struct S { int i; S() =3D default; };</div><div><br=
></div><div>=E2=80=94 we had is_trivial_according_to_the_standard(func) and=
 yet must_produce_an_observable_effect(func), we&#39;d lose this convenient=
 equivalence, at which point I&#39;d question the utility of the notion of =
&quot;trivial function&quot; at all.</div><div><br></div><div>Of course thi=
s is all completely hypothetical and counterfactual. I don&#39;t mean to su=
ggest that this zero-initialization idea has a snowball&#39;s chance of get=
ting in front of the committee. Just engaging in some proof-by-contradictio=
n here. :)</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KZ088Fon-LwN4wBdNjjJi0tnXHBjts=
LB7faQ5qRfVFug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KZ088Fon-L=
wN4wBdNjjJi0tnXHBjtsLB7faQ5qRfVFug%40mail.gmail.com</a>.<br />

--001a114a0104e0f7a3054563beea--

.

------=_Part_472_355531375.1483682540535
Content-Type: multipart/alternative;
 boundary="----=_Part_473_520734651.1483682540535"

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

On Thursday, January 5, 2017 at 9:26:32 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Thu, Jan 5, 2017 at 5:31 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Thursday, January 5, 2017 at 7:54:40 PM UTC-5, Arthur O'Dwyer wrote:
>>>
>>> On Thursday, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote=
:
>>>>
>>>>
>>>> Changing the default means all constructors (including inline ones!)=
=20
>>>> must=20
>>>> zero-intialise, even variables whose contents are protected by other=
=20
>>>> member=20
>>>> variables, =C3=A0 la std::optional.
>>>>
>>>
>>> In fact, wouldn't standardizing "zero by default" mean that no=20
>>> constructor could ever be trivial, unless it was the constructor of an=
=20
>>> empty class?
>>>
>>
>> Technically, no. Zero-initialization of a trivial type should be handled=
=20
>> by the code performing the initialization, rather than the type's=20
>> constructor.
>>
>
> Yeah, I should have worded that differently. I meant that in C++ today,=
=20
> there is a very convenient equivalence between=20
> is_trivial_according_to_the_standard(func) and=20
> has_no_observable_effect_on_the_machine(func).  If we were to change the=
=20
> language semantics so that for some "func"s, such as S::S() here =E2=80=
=94
>
>     struct S { int i; S() =3D default; };
>
> =E2=80=94 we had is_trivial_according_to_the_standard(func) and yet=20
> must_produce_an_observable_effect(func), we'd lose this convenient=20
> equivalence, at which point I'd question the utility of the notion of=20
> "trivial function" at all.
>

The only trivial constructs that behaves as you suggest are trivial default=
=20
constructors and trivial destructors. Trivial copy and move constructors=20
actually "produce an observable effect". And a very useful one.

So I contest your equating "triviality" with "do nothing". The standard=20
seems to use it to mean "no user-defined code".

After all, even invoking a trivial default constructor can still have an=20
observable effect: if the object is static or global, it will be=20
zero-initialized, despite the use of a trivial default constructor.
=20

> Of course this is all completely hypothetical and counterfactual. I don't=
=20
> mean to suggest that this zero-initialization idea has a snowball's chanc=
e=20
> of getting in front of the committee.
>

Well it might have a chance of getting in front of the committee. But=20
mainly as comic relief ;)

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/18a060e8-2588-4ae6-a726-5ef4aeb319e3%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 9:26:32 PM UTC-5, Arthur O=
&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thu, Jan 5, 2017 at 5:31 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pFG-VWM2DAAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gm=
ail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span>On Thursday, January 5, 2017 at 7:54:40 PM UT=
C-5, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Thursday=
, January 5, 2017 at 9:49:20 AM UTC-8, Thiago Macieira wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><br>Changing the default means all constructors (including inline ones!)=
 must=20
<br>zero-intialise, even variables whose contents are protected by other me=
mber=20
<br>variables, =C3=A0 la std::optional.<br></blockquote><div><br></div><div=
>In fact, wouldn&#39;t standardizing &quot;zero by default&quot; mean that =
no constructor could ever be trivial, unless it was the constructor of an e=
mpty class?</div></div></blockquote></span><div><br>Technically, no. Zero-i=
nitialization of a trivial type should be handled by the code performing th=
e initialization, rather than the type&#39;s constructor.<br></div></div></=
blockquote><div><br></div><div>Yeah, I should have worded that differently.=
 I meant that in C++ today, there is a very convenient equivalence between =
is_trivial_according_to_the_<wbr>standard(func) and has_no_observable_effec=
t_on_<wbr>the_machine(func).=C2=A0 If we were to change the language semant=
ics so that for some &quot;func&quot;s, such as S::S() here =E2=80=94</div>=
<div><br></div><div>=C2=A0 =C2=A0 struct S { int i; S() =3D default; };</di=
v><div><br></div><div>=E2=80=94 we had is_trivial_according_to_the_<wbr>sta=
ndard(func) and yet must_produce_an_observable_<wbr>effect(func), we&#39;d =
lose this convenient equivalence, at which point I&#39;d question the utili=
ty of the notion of &quot;trivial function&quot; at all.</div></div></div><=
/div></blockquote><div><br>The only trivial constructs that behaves as you =
suggest are trivial default constructors and trivial destructors. Trivial c=
opy and move constructors actually &quot;produce an observable effect&quot;=
.. And a very useful one.<br><br>So I contest your equating &quot;triviality=
&quot; with &quot;do nothing&quot;. The standard seems to use it to mean &q=
uot;no user-defined code&quot;.<br><br>After all, even invoking a trivial d=
efault constructor can still have an observable effect: if the object is st=
atic or global, it will be zero-initialized, despite the use of a trivial d=
efault constructor.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>Of c=
ourse this is all completely hypothetical and counterfactual. I don&#39;t m=
ean to suggest that this zero-initialization idea has a snowball&#39;s chan=
ce of getting in front of the committee.</div></div></div></div></blockquot=
e><div><br>Well it might have a chance of getting in front of the committee=
.. But mainly as comic relief ;)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/18a060e8-2588-4ae6-a726-5ef4aeb319e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18a060e8-2588-4ae6-a726-5ef4aeb319e3=
%40isocpp.org</a>.<br />

------=_Part_473_520734651.1483682540535--

------=_Part_472_355531375.1483682540535--

.

--001a11443f0ce5360f054568f9da
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 6, 2017 at 12:54 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

>
> I think this is a great proposal... *for an optimization level*.
> It seems to be in the spirit of -fwrapv / -ftrapv / -fno-strict-aliasing =
/
> -Odebug. You have some C++ code whose behavior you *believe* to be
> defined (or else you wouldn't be compiling it), and you just want to chan=
ge
> the *particular machine instructions* emitted by the compiler for this
> code =E2=80=94 such that the code will get slower, but the heap will look=
 nicer in
> the debugger.  This is a perfectly valid optimization tradeoff, and I
> encourage vendors to go out and implement it as an option; but IMO it has
> nothing to do with the *language-level semantics* of C++.
>
>
I'd shy from including this in any optimisation level, but it'd make a fine
debug option I guess. MSVC already does something like this in debug mode.

Then again, for many real debugging purposes, as mentioned, we seem better
served by the current behaviour, preserving UB so that UBsan et al can pick
up on it more easily, as then the programmer's intention is clear (rather
than implicit and possibly wrong).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CACGiwhGjQfrYp%3D8BAVQS545Wz2Z78c1sogVz6uik-WrQD=
Gy0SA%40mail.gmail.com.

--001a11443f0ce5360f054568f9da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Jan 6, 2017 at 12:54 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<=
a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwy=
er@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><span class=3D""></span><br><div>I think this is a great proposa=
l... <i>for an optimization level</i>.</div><div>It seems to be in the spir=
it of -fwrapv / -ftrapv / -fno-strict-aliasing / -Odebug. You have some C++=
 code whose behavior you <i>believe</i> to be defined (or else you wouldn&#=
39;t be compiling it), and you just want to change the <i>particular machin=
e instructions</i> emitted by the compiler for this code =E2=80=94 such tha=
t the code will get slower, but the heap will look nicer in the debugger.=
=C2=A0 This is a perfectly valid optimization tradeoff, and I encourage ven=
dors to go out and implement it as an option; but IMO it has nothing to do =
with the <i>language-level semantics</i>=C2=A0of C++.</div><br></div></bloc=
kquote><div><br></div><div>I&#39;d shy from including this in any optimisat=
ion level, but it&#39;d make a fine debug option I guess. MSVC already does=
 something like this in debug mode.<br><br></div><div>Then again, for many =
real debugging purposes, as mentioned, we seem better served by the current=
 behaviour, preserving UB so that UBsan et al can pick up on it more easily=
, as then the programmer&#39;s intention is clear (rather than implicit and=
 possibly wrong).<br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGjQfrYp%3D8BAVQS545Wz2Z78c1sog=
Vz6uik-WrQDGy0SA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGjQfrYp%=
3D8BAVQS545Wz2Z78c1sogVz6uik-WrQDGy0SA%40mail.gmail.com</a>.<br />

--001a11443f0ce5360f054568f9da--

.

Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 18:43:08 PST, D. B. escreveu=
:
> My other objections are the fact that C++ generally tries not to
> incorporate behaviour that's precisely the opposite of what C does

That's another very good point. Take the following function that could be=
=20
found in a header:

struct SomeData {
 int state;
 int data[4];
};

static inline struct SomeData data_create()
{
 struct SomeData d;
 d.state =3D 0;
 return d;
}

If the above is compiled in C, it will compile to different code than it wo=
uld=20
compile with the C++ compiler. Mind you, the difference is not observable,=
=20
since observing it would mean inspecting uninitialised memory, which means =
UB.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2194992.FJ1NVjZUaV%40tjmaciei-mobl1.

.

Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 16:54:39 PST, Arthur O'Dwyer=
=20
escreveu:
> In fact, wouldn't standardizing "zero by default" mean that no constructo=
r
> could ever be trivial, unless it was the constructor of an empty class?
> (And if you additionally propose to initialize padding bytes to zero, the=
n
> you can get rid of even that special case! ;))

The following is a trivial constructor:

struct Type
{
 int state;
 constexpr Type() : state(0) {}
};

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1494562.ol5OfVilBX%40tjmaciei-mobl1.

.

------=_Part_213_1070444501.1483715873649
Content-Type: multipart/alternative;
 boundary="----=_Part_214_1644501791.1483715873650"

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



On Friday, January 6, 2017 at 9:34:11 AM UTC-5, Thiago Macieira wrote:
>
> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 16:54:39 PST, Arthur O'Dwy=
er=20
> escreveu:=20
> > In fact, wouldn't standardizing "zero by default" mean that no=20
> constructor=20
> > could ever be trivial, unless it was the constructor of an empty class?=
=20
> > (And if you additionally propose to initialize padding bytes to zero,=
=20
> then=20
> > you can get rid of even that special case! ;))=20
>
> The following is a trivial constructor:=20
>
> struct Type=20
> {=20
>         int state;=20
>         constexpr Type() : state(0) {}=20
> };
>

No, it isn't. That constructor is user-provided. It is user-declared and=20
not defaulted/deleted on its first declaration.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0a8cf232-2c8d-4ff4-b59b-7eb4c9ac8eb8%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Friday, January 6, 2017 at 9:34:11 AM UTC-5, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em quinta-=
feira, 5 de janeiro de 2017, =C3=A0s 16:54:39 PST, Arthur O&#39;Dwyer=20
<br>escreveu:
<br>&gt; In fact, wouldn&#39;t standardizing &quot;zero by default&quot; me=
an that no constructor
<br>&gt; could ever be trivial, unless it was the constructor of an empty c=
lass?
<br>&gt; (And if you additionally propose to initialize padding bytes to ze=
ro, then
<br>&gt; you can get rid of even that special case! ;))
<br>
<br>The following is a trivial constructor:
<br>
<br>struct Type
<br>{
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int state;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0constexpr Type() : stat=
e(0) {}
<br>};<br></blockquote><div><br>No, it isn&#39;t. That constructor is user-=
provided. It is user-declared and not defaulted/deleted on its first declar=
ation.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a8cf232-2c8d-4ff4-b59b-7eb4c9ac8eb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a8cf232-2c8d-4ff4-b59b-7eb4c9ac8eb8=
%40isocpp.org</a>.<br />

------=_Part_214_1644501791.1483715873650--

------=_Part_213_1070444501.1483715873649--

.

On 2017-01-05 19:54, Arthur O'Dwyer wrote:
> In fact, wouldn't standardizing "zero by default" mean that no constructor
> could ever be trivial, unless it was the constructor of an empty class?

I think that, if such a feature were to ever happen (whether in the
language or as a compiler option or whatever), it would be implemented
by requiring whoever *reserves memory* to zero-initialize. IOW, `new`
would ultimately call `calloc` instead of `malloc` (or something
equivalent to that idea), and adjustment of the stack pointer to
"allocate" on the stack would be followed by zeroing out that memory.
This would happen *prior* to an object being constructed in said memory,
so constructors could still be trivial.

On 2017-01-06 01:02, Nicol Bolas wrote:
> After all, even invoking a trivial default constructor can still have an
> observable effect: if the object is static or global, it will be
> zero-initialized, despite the use of a trivial default constructor.

....but this likewise happens because the entire address space for static
storage is zero initialized. The initialization isn't done by
constructors, for individual objects, it's done for the whole address
space (I believe all at once).

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/586FB582.2010106%40gmail.com.

.

------=_Part_209_302151260.1483717541371
Content-Type: multipart/alternative;
 boundary="----=_Part_210_468974094.1483717541371"

------=_Part_210_468974094.1483717541371
Content-Type: text/plain; charset=UTF-8

On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:
>
> Back in the day, the C decision to not initialize variables implicitly
> made sense.  Processors were slow, and optimizers weren't able to
> identify and remove redundant assignments.  These days however it's a
> source of bugs, and we have tools like placement new to delay
> initialization until the moment it is needed.
>
> I propose to reverse this, and zero-initialize scalars in functions and
> structs.  For the cases where there is a performance impact, introduce a
> value std::uninitialized of type std::uninitialized_t, and define
> initialization of a scalar type from an std::uninitialized_t as the
> current behavior.
>
>
Other people have already commented about the performance impact of this
proposal. For me the biggest issue is another:
right now the compiler warns me if in a function I use a variable without
initializing it in some code path. If it was always initialized by default
to 0 and code started relying on this behaviour,  compilers would have to
stop issuing these useful warnings.

-- gpd

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67856385-7bf1-449a-9d70-6e4de0e7ab34%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Back in the day, the C =
decision to not initialize variables implicitly=20
<br>made sense. =C2=A0Processors were slow, and optimizers weren&#39;t able=
 to=20
<br>identify and remove redundant assignments. =C2=A0These days however it&=
#39;s a=20
<br>source of bugs, and we have tools like placement new to delay=20
<br>initialization until the moment it is needed.
<br>
<br>I propose to reverse this, and zero-initialize scalars in functions and=
=20
<br>structs. =C2=A0For the cases where there is a performance impact, intro=
duce a=20
<br>value std::uninitialized of type std::uninitialized_t, and define=20
<br>initialization of a scalar type from an std::uninitialized_t as the=20
<br>current behavior.
<br>
<br></blockquote><div><br>Other people have already commented about the per=
formance impact of this proposal. For me the biggest issue is another:<br>r=
ight now the compiler warns me if in a function I use a variable without in=
itializing it in some code path. If it was always initialized by default to=
 0 and code started relying on this behaviour,=C2=A0 compilers would have t=
o stop issuing these useful warnings.<br><br>-- gpd<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67856385-7bf1-449a-9d70-6e4de0e7ab34%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67856385-7bf1-449a-9d70-6e4de0e7ab34=
%40isocpp.org</a>.<br />

------=_Part_210_468974094.1483717541371--

------=_Part_209_302151260.1483717541371--

.

--001a11423f443f369d05456efc4f
Content-Type: text/plain; charset=UTF-8

Right - even if you *meant* it not to be 0. I think a couple of other
people mentioned this as an objection too. It basically means that now the
compiler must assume the use of any variable is OK (in terms of being
initialised), when in terms of the program's semantics, it might not be.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia2K0Yb3cvABYF8rwCS7Kubc9mv%2BHP7UfDODfA%40mail.gmail.com.

--001a11423f443f369d05456efc4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Right - even if you <i>meant</i> it not to be 0. I think a=
 couple of other people mentioned this as an objection too. It basically me=
ans that now the compiler must assume the use of any variable is OK (in ter=
ms of being initialised), when in terms of the program&#39;s semantics, it =
might not be.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia2K0Yb3cvABYF8rwCS7Kubc=
9mv%2BHP7UfDODfA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia=
2K0Yb3cvABYF8rwCS7Kubc9mv%2BHP7UfDODfA%40mail.gmail.com</a>.<br />

--001a11423f443f369d05456efc4f--

.

--001a114d5198dee35605456f8425
Content-Type: text/plain; charset=UTF-8

Why zero? Why not a trap representation? Why not explicitly random data (as
having memory zero'd while debugging or developing often leads to very
strange behavior and even crashes when release modes are active)?
These are just as "consistent" as zero, so I don't see why zero should be
preferred if that is the issue.

Zero'ing doesn't seem to prevent bugs, it just changes them, so that's also
not consistent reasoning either.

On Fri, Jan 6, 2017 at 10:51 AM, D. B. <db0451@gmail.com> wrote:

> Right - even if you *meant* it not to be 0. I think a couple of other
> people mentioned this as an objection too. It basically means that now the
> compiler must assume the use of any variable is OK (in terms of being
> initialised), when in terms of the program's semantics, it might not be.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia2K0Yb3cvABYF8rw
> CS7Kubc9mv%2BHP7UfDODfA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia2K0Yb3cvABYF8rwCS7Kubc9mv%2BHP7UfDODfA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Gi74q4GxQP-%2B2Y-9q43LQyjptbZkkEwrCLc2q_zkq6A%40mail.gmail.com.

--001a114d5198dee35605456f8425
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why zero? Why not a trap representation? Why not explicitl=
y random data (as having memory zero&#39;d while debugging or developing of=
ten leads to very strange behavior and even crashes when release modes are =
active)?=C2=A0<div>These are just as &quot;consistent&quot; as zero, so I d=
on&#39;t see why zero should be preferred if that is the issue.</div><div><=
br></div><div>Zero&#39;ing doesn&#39;t seem to prevent bugs, it just change=
s them, so that&#39;s also not consistent reasoning either.</div></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jan 6, 2017 a=
t 10:51 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gmail.com"=
 target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Right - even if you <i>meant</i> it not t=
o be 0. I think a couple of other people mentioned this as an objection too=
.. It basically means that now the compiler must assume the use of any varia=
ble is OK (in terms of being initialised), when in terms of the program&#39=
;s semantics, it might not be.<br></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFrgPrAia2K0Yb3cvABYF8rwCS7Kubc=
9mv%2BHP7UfDODfA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CACGiwhFrgPrAia2K0Yb3cvABYF8rw<wbr>CS7Kubc9mv%2BHP7Uf=
DODfA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Gi74q4GxQP-%2B2Y-9q43LQyjptbZ=
kkEwrCLc2q_zkq6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Gi74q4G=
xQP-%2B2Y-9q43LQyjptbZkkEwrCLc2q_zkq6A%40mail.gmail.com</a>.<br />

--001a114d5198dee35605456f8425--

.

--001a114cc80cf86e4205456fe434
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 4:29 PM, Ren Industries <renindustries@gmail.com>
wrote:

> Why zero? Why not a trap representation? Why not explicitly random data
> (as having memory zero'd while debugging or developing often leads to very
> strange behavior and even crashes when release modes are active)?
> These are just as "consistent" as zero, so I don't see why zero should be
> preferred if that is the issue.
>

Don't ask me; it's not my proposal.



> Zero'ing doesn't seem to prevent bugs, it just changes them, so that's
> also not consistent reasoning either.
>

It'll prevent diagnosing bugs if every object is always in a valid
initialised state, letting users forget to 'reinitialise' them with a
non-default value but not warning them anymore.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDRm%3Dm4zo71m12cMoLx6YSROSG1wiUNfjOR5EwQ%40mail.gmail.com.

--001a114cc80cf86e4205456fe434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 4:29 PM, Ren Industries <span dir=3D"ltr">&lt;<a href=3D=
"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Wh=
y zero? Why not a trap representation? Why not explicitly random data (as h=
aving memory zero&#39;d while debugging or developing often leads to very s=
trange behavior and even crashes when release modes are active)?=C2=A0<div>=
These are just as &quot;consistent&quot; as zero, so I don&#39;t see why ze=
ro should be preferred if that is the issue.</div></div></blockquote><div><=
br></div><div>Don&#39;t ask me; it&#39;s not my proposal.<br><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Zero&#39;=
ing doesn&#39;t seem to prevent bugs, it just changes them, so that&#39;s a=
lso not consistent reasoning either.</div></div></blockquote><div><br></div=
><div>It&#39;ll prevent diagnosing bugs if every object is always in a vali=
d initialised state, letting users forget to &#39;reinitialise&#39; them wi=
th a non-default value but not warning them anymore.<br></div></div></div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDRm%3Dm4zo71m12cMoLx6YSR=
OSG1wiUNfjOR5EwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDR=
m%3Dm4zo71m12cMoLx6YSROSG1wiUNfjOR5EwQ%40mail.gmail.com</a>.<br />

--001a114cc80cf86e4205456fe434--

.

--001a1149dbf48af1ab0545741848
Content-Type: text/plain; charset=UTF-8

Sorry, didn't mean to reply to you, was more a general question to OP

On Fri, Jan 6, 2017 at 11:56 AM, D. B. <db0451@gmail.com> wrote:

> On Fri, Jan 6, 2017 at 4:29 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> Why zero? Why not a trap representation? Why not explicitly random data
>> (as having memory zero'd while debugging or developing often leads to very
>> strange behavior and even crashes when release modes are active)?
>> These are just as "consistent" as zero, so I don't see why zero should be
>> preferred if that is the issue.
>>
>
> Don't ask me; it's not my proposal.
>
>
>
>> Zero'ing doesn't seem to prevent bugs, it just changes them, so that's
>> also not consistent reasoning either.
>>
>
> It'll prevent diagnosing bugs if every object is always in a valid
> initialised state, letting users forget to 'reinitialise' them with a
> non-default value but not warning them anymore.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDRm%
> 3Dm4zo71m12cMoLx6YSROSG1wiUNfjOR5EwQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDRm%3Dm4zo71m12cMoLx6YSROSG1wiUNfjOR5EwQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8QuPsdqKctKn_3y8m90nrw8Pd3XQTZsNZ53uWGN%2BkdLw%40mail.gmail.com.

--001a1149dbf48af1ab0545741848
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, didn&#39;t mean to reply to you, was more a general=
 question to OP</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jan 6, 2017 at 11:56 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D=
"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Jan 6, 2017 =
at 4:29 PM, Ren Industries <span dir=3D"ltr">&lt;<a href=3D"mailto:renindus=
tries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why zero? Why not =
a trap representation? Why not explicitly random data (as having memory zer=
o&#39;d while debugging or developing often leads to very strange behavior =
and even crashes when release modes are active)?=C2=A0<div>These are just a=
s &quot;consistent&quot; as zero, so I don&#39;t see why zero should be pre=
ferred if that is the issue.</div></div></blockquote><div><br></div></span>=
<div>Don&#39;t ask me; it&#39;s not my proposal.<br><br></div><span class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Zero&#39;ing doesn&#39;t seem to prevent bugs, it just changes them, so th=
at&#39;s also not consistent reasoning either.</div></div></blockquote><div=
><br></div></span><div>It&#39;ll prevent diagnosing bugs if every object is=
 always in a valid initialised state, letting users forget to &#39;reinitia=
lise&#39; them with a non-default value but not warning them anymore.<br></=
div></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFpYPSYDRm%3Dm4zo71m12cMoLx6YSR=
OSG1wiUNfjOR5EwQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CACGiwhFpYPSYDRm%<wbr>3Dm4zo71m12cMoLx6YSROSG1wiUNfj<wbr>O=
R5EwQ%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8QuPsdqKctKn_3y8m90nrw8Pd3XQTZ=
sNZ53uWGN%2BkdLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8QuPsdqK=
ctKn_3y8m90nrw8Pd3XQTZsNZ53uWGN%2BkdLw%40mail.gmail.com</a>.<br />

--001a1149dbf48af1ab0545741848--

.

--001a114cc80cb4a09b0545749dcc
Content-Type: text/plain; charset=UTF-8

Indeed, that seems very obvious now; I guess I wasn't really paying
attention earlier. :)

As to "why zero", ultimately the answer is because it happens to be mostly
convenient for the OP and their use cases (and/or disregard for CPU time),
with the precedent of static initialisation being useful for their
argument. The key thing is that it would be massively inconvenient for many
other users, both from performance and diagnostic perspective.

Filling 'pre-initialised' memory with a trap representation struck me as
quite interesting as a possible debugging tool - but surely is not
something that can be standard due to being architecture-dependent, and
probably cannot be of huge utility as an implementation-defined feature -
due to mainstream CPUs not having any free representations for ints, for
example.

As for "explicitly random data", that would seem to have the same problem
for performance, while not offering OP's cited benefits to predictability.
But then I suspect it wasn't really a serious suggestion. :D

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFo%3DDWCeL51_U4Xn2dZnmj0hqNN3Oogb1MCJJ%2Bg8ssqhw%40mail.gmail.com.

--001a114cc80cb4a09b0545749dcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Indeed, that seems very obvious now; I gues=
s I wasn&#39;t really paying attention earlier. :)<br><br></div>As to &quot=
;why zero&quot;, ultimately the answer is because it happens to be mostly c=
onvenient for the OP and their use cases (and/or disregard for CPU time), w=
ith the precedent of static initialisation being useful for their argument.=
 The key thing is that it would be massively inconvenient for many other us=
ers, both from performance and diagnostic perspective.<br><br></div>Filling=
 &#39;pre-initialised&#39; memory with a trap representation struck me as q=
uite interesting as a possible debugging tool - but surely is not something=
 that can be standard due to being architecture-dependent, and probably can=
not be of huge utility as an implementation-defined feature - due to mainst=
ream CPUs not having any free representations for ints, for example.<br><br=
></div>As for &quot;explicitly random data&quot;, that would seem to have t=
he same problem for performance, while not offering OP&#39;s cited benefits=
 to predictability. But then I suspect it wasn&#39;t really a serious sugge=
stion. :D<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFo%3DDWCeL51_U4Xn2dZnmj0hqNN3O=
ogb1MCJJ%2Bg8ssqhw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFo%3DD=
WCeL51_U4Xn2dZnmj0hqNN3Oogb1MCJJ%2Bg8ssqhw%40mail.gmail.com</a>.<br />

--001a114cc80cb4a09b0545749dcc--

.

------=_Part_342_1108759932.1483746092825
Content-Type: multipart/alternative;
 boundary="----=_Part_343_628099080.1483746092825"

------=_Part_343_628099080.1483746092825
Content-Type: text/plain; charset=UTF-8



On Friday, January 6, 2017 at 10:45:41 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:
>>
>> Back in the day, the C decision to not initialize variables implicitly
>> made sense.  Processors were slow, and optimizers weren't able to
>> identify and remove redundant assignments.  These days however it's a
>> source of bugs, and we have tools like placement new to delay
>> initialization until the moment it is needed.
>>
>> I propose to reverse this, and zero-initialize scalars in functions and
>> structs.  For the cases where there is a performance impact, introduce a
>> value std::uninitialized of type std::uninitialized_t, and define
>> initialization of a scalar type from an std::uninitialized_t as the
>> current behavior.
>>
>>
> Other people have already commented about the performance impact of this
> proposal. For me the biggest issue is another:
> right now the compiler warns me if in a function I use a variable without
> initializing it in some code path. If it was always initialized by default
> to 0 and code started relying on this behaviour,  compilers would have to
> stop issuing these useful warnings.
>
> -- gpd
>

I've seen that objection before, but if you truly believe that, why should
it only apply to primitive types and aggregates containing them? Do you
write most of your classes without default constructors to force users to
explicitly initialize them? Would you argue that it would be better if
std::string and the containers didn't have default constructors so
compilers would warn if you didn't provide an explicit initialization? How
about the fact that all containers are specified to value-initialize their
members, so std::vector<int>(10) gives you an array of 10 zeros and
map_of_counters[some_key]++ works correctly even if some_key isn't in the
map yet? It seems inconsistent to think that relying on any of those
results in "good" code but it would somehow be "bad" if code relied on that
behavior of primitives. In my mind, any difference between user-defined
types and primitives should be considered a bug rather than a feature.

Would this proposal be more palatable if phrased as "make
value-construction the default and default-construction the exception"? It
is already how things work in containers and you need to go through a lot
more effort than using something like std::uninitialized to make them
default construct instead. It is also already the case that
std::make_unique can only do value initialization and is incapable of
default construction and many projects are using it instead of bare uses of
new.

Alternatively, how would you feel about an additional set of primitive
types that provided value initialization semantics? Then projects that want
good defaults could just switch to using them except in the few cases where
they want uninitialized memory. Ideally C and C++ could agree on the naming
such that the types could be shared.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c4522ad-4e9d-4bcf-ad6c-edd4ab309033%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, January 6, 2017 at 10:45:41 AM UTC-5, G=
iovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">Back in the day, the C decisio=
n to not initialize variables implicitly=20
<br>made sense. =C2=A0Processors were slow, and optimizers weren&#39;t able=
 to=20
<br>identify and remove redundant assignments. =C2=A0These days however it&=
#39;s a=20
<br>source of bugs, and we have tools like placement new to delay=20
<br>initialization until the moment it is needed.
<br>
<br>I propose to reverse this, and zero-initialize scalars in functions and=
=20
<br>structs. =C2=A0For the cases where there is a performance impact, intro=
duce a=20
<br>value std::uninitialized of type std::uninitialized_t, and define=20
<br>initialization of a scalar type from an std::uninitialized_t as the=20
<br>current behavior.
<br>
<br></blockquote><div><br>Other people have already commented about the per=
formance impact of this proposal. For me the biggest issue is another:<br>r=
ight now the compiler warns me if in a function I use a variable without in=
itializing it in some code path. If it was always initialized by default to=
 0 and code started relying on this behaviour,=C2=A0 compilers would have t=
o stop issuing these useful warnings.<br><br>-- gpd<br></div></div></blockq=
uote><div><br></div><div>I&#39;ve seen that objection before, but if you tr=
uly believe that, why should it only apply to primitive types and aggregate=
s containing them? Do you write most of your classes without default constr=
uctors to force users to explicitly initialize them? Would you argue that i=
t would be better if std::string and the containers didn&#39;t have default=
 constructors so compilers would warn if you didn&#39;t provide an explicit=
 initialization? How about the fact that all containers are specified to va=
lue-initialize their members, so std::vector&lt;int&gt;(10) gives you an ar=
ray of 10 zeros and map_of_counters[some_key]++ works correctly even if som=
e_key isn&#39;t in the map yet? It seems inconsistent to think that relying=
 on any of those results in &quot;good&quot; code but it would somehow be &=
quot;bad&quot; if code relied on that behavior of primitives. In my mind, a=
ny difference between user-defined types and primitives should be considere=
d a bug rather than a feature.</div><div><br></div><div>Would this proposal=
 be more palatable if phrased as &quot;make value-construction the default =
and default-construction the exception&quot;? It is already how things work=
 in containers and you need to go through a lot more effort than using some=
thing like std::uninitialized to make them default construct instead. It is=
 also already the case that std::make_unique can only do value initializati=
on and is incapable of default construction and many projects are using it =
instead of bare uses of new.</div><div><br></div><div>Alternatively, how wo=
uld you feel about an additional set of primitive types that provided value=
 initialization semantics? Then projects that want good defaults could just=
 switch to using them except in the few cases where they want uninitialized=
 memory. Ideally C and C++ could agree on the naming such that the types co=
uld be shared.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5c4522ad-4e9d-4bcf-ad6c-edd4ab309033%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c4522ad-4e9d-4bcf-ad6c-edd4ab309033=
%40isocpp.org</a>.<br />

------=_Part_343_628099080.1483746092825--

------=_Part_342_1108759932.1483746092825--

.

--f403045ceecaab8171054575b1d2
Content-Type: text/plain; charset=UTF-8

On 6 January 2017 at 15:41, Mathias Stearn <redbeard0531@gmail.com> wrote:

> On Friday, January 6, 2017 at 10:45:41 AM UTC-5, Giovanni Piero Deretta
> wrote:
>>
>> On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:
>>>
>>> Back in the day, the C decision to not initialize variables implicitly
>>> made sense.  Processors were slow, and optimizers weren't able to
>>> identify and remove redundant assignments.  These days however it's a
>>> source of bugs, and we have tools like placement new to delay
>>> initialization until the moment it is needed.
>>>
>>> I propose to reverse this, and zero-initialize scalars in functions and
>>> structs.  For the cases where there is a performance impact, introduce a
>>> value std::uninitialized of type std::uninitialized_t, and define
>>> initialization of a scalar type from an std::uninitialized_t as the
>>> current behavior.
>>>
>>>
>> Other people have already commented about the performance impact of this
>> proposal. For me the biggest issue is another:
>> right now the compiler warns me if in a function I use a variable without
>> initializing it in some code path. If it was always initialized by default
>> to 0 and code started relying on this behaviour,  compilers would have to
>> stop issuing these useful warnings.
>>
>> -- gpd
>>
>
> I've seen that objection before, but if you truly believe that, why should
> it only apply to primitive types and aggregates containing them? Do you
> write most of your classes without default constructors to force users to
> explicitly initialize them? Would you argue that it would be better if
> std::string and the containers didn't have default constructors so
> compilers would warn if you didn't provide an explicit initialization? How
> about the fact that all containers are specified to value-initialize their
> members, so std::vector<int>(10) gives you an array of 10 zeros and
> map_of_counters[some_key]++ works correctly even if some_key isn't in the
> map yet?
>

The fact that you can't resize a string or vector without initializing its
elements is a measurable and significant performance problem for some
applications; I have seen people invent their own string type or do truly
horrible things to std::string (directly poking at its internals) to
circumvent that.

It seems inconsistent to think that relying on any of those results in
> "good" code but it would somehow be "bad" if code relied on that behavior
> of primitives. In my mind, any difference between user-defined types and
> primitives should be considered a bug rather than a feature.
>
> Would this proposal be more palatable if phrased as "make
> value-construction the default and default-construction the exception"? It
> is already how things work in containers and you need to go through a lot
> more effort than using something like std::uninitialized to make them
> default construct instead. It is also already the case that
> std::make_unique can only do value initialization and is incapable of
> default construction and many projects are using it instead of bare uses of
> new.
>
> Alternatively, how would you feel about an additional set of primitive
> types that provided value initialization semantics? Then projects that want
> good defaults could just switch to using them except in the few cases where
> they want uninitialized memory. Ideally C and C++ could agree on the naming
> such that the types could be shared.
>

That seems like an overengineered solution. Why not just turn on your
compiler's most noisy "might be used uninitialized" warnings
(-Werror=uninitialized or similar) and add the explicit '= 0;'s ?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnyLcT-90p9Kqo8R_DDN%2Bj%2ByRpaoHHfHz5_EoUkP-jyVg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 6=
 January 2017 at 15:41, Mathias Stearn <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:redbeard0531@gmail.com" target=3D"_blank">redbeard0531@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cl=
ass=3D"">On Friday, January 6, 2017 at 10:45:41 AM UTC-5, Giovanni Piero De=
retta wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thu=
rsday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">Back in the day, the C decision to not initialize v=
ariables implicitly=20
<br>made sense.=C2=A0 Processors were slow, and optimizers weren&#39;t able=
 to=20
<br>identify and remove redundant assignments.=C2=A0 These days however it&=
#39;s a=20
<br>source of bugs, and we have tools like placement new to delay=20
<br>initialization until the moment it is needed.
<br>
<br>I propose to reverse this, and zero-initialize scalars in functions and=
=20
<br>structs.=C2=A0 For the cases where there is a performance impact, intro=
duce a=20
<br>value std::uninitialized of type std::uninitialized_t, and define=20
<br>initialization of a scalar type from an std::uninitialized_t as the=20
<br>current behavior.
<br>
<br></blockquote><div><br>Other people have already commented about the per=
formance impact of this proposal. For me the biggest issue is another:<br>r=
ight now the compiler warns me if in a function I use a variable without in=
itializing it in some code path. If it was always initialized by default to=
 0 and code started relying on this behaviour,=C2=A0 compilers would have t=
o stop issuing these useful warnings.<br><br>-- gpd<br></div></div></blockq=
uote><div><br></div></span><div>I&#39;ve seen that objection before, but if=
 you truly believe that, why should it only apply to primitive types and ag=
gregates containing them? Do you write most of your classes without default=
 constructors to force users to explicitly initialize them? Would you argue=
 that it would be better if std::string and the containers didn&#39;t have =
default constructors so compilers would warn if you didn&#39;t provide an e=
xplicit initialization? How about the fact that all containers are specifie=
d to value-initialize their members, so std::vector&lt;int&gt;(10) gives yo=
u an array of 10 zeros and map_of_counters[some_key]++ works correctly even=
 if some_key isn&#39;t in the map yet?</div></div></blockquote><div><br></d=
iv><div>The fact that you can&#39;t resize a string or vector without initi=
alizing its elements is a measurable and significant performance problem fo=
r some applications; I have seen people invent their own string type or do =
truly horrible things to std::string (directly poking at its internals) to =
circumvent that.</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>It seems inconsistent to think that relying on any of those =
results in &quot;good&quot; code but it would somehow be &quot;bad&quot; if=
 code relied on that behavior of primitives. In my mind, any difference bet=
ween user-defined types and primitives should be considered a bug rather th=
an a feature.</div><div><br></div><div>Would this proposal be more palatabl=
e if phrased as &quot;make value-construction the default and default-const=
ruction the exception&quot;? It is already how things work in containers an=
d you need to go through a lot more effort than using something like std::u=
ninitialized to make them default construct instead. It is also already the=
 case that std::make_unique can only do value initialization and is incapab=
le of default construction and many projects are using it instead of bare u=
ses of new.</div><div><br></div><div>Alternatively, how would you feel abou=
t an additional set of primitive types that provided value initialization s=
emantics? Then projects that want good defaults could just switch to using =
them except in the few cases where they want uninitialized memory. Ideally =
C and C++ could agree on the naming such that the types could be shared.</d=
iv></div></blockquote><div><br></div><div>That seems like an overengineered=
 solution. Why not just turn on your compiler&#39;s most noisy &quot;might =
be used uninitialized&quot; warnings (-Werror=3Duninitialized or similar) a=
nd add the explicit &#39;=3D 0;&#39;s ?</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnyLcT-90p9Kqo8R_DDN%2Bj%2ByRpa=
oHHfHz5_EoUkP-jyVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnyLcT-=
90p9Kqo8R_DDN%2Bj%2ByRpaoHHfHz5_EoUkP-jyVg%40mail.gmail.com</a>.<br />

--f403045ceecaab8171054575b1d2--

.

------=_Part_392_1539831339.1483748496399
Content-Type: multipart/alternative;
 boundary="----=_Part_393_235413202.1483748496400"

------=_Part_393_235413202.1483748496400
Content-Type: text/plain; charset=UTF-8

On Friday, January 6, 2017 at 6:41:32 PM UTC-5, Mathias Stearn wrote:
>
> On Friday, January 6, 2017 at 10:45:41 AM UTC-5, Giovanni Piero Deretta
> wrote:
>>
>> On Thursday, January 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:
>>>
>>> Back in the day, the C decision to not initialize variables implicitly
>>> made sense.  Processors were slow, and optimizers weren't able to
>>> identify and remove redundant assignments.  These days however it's a
>>> source of bugs, and we have tools like placement new to delay
>>> initialization until the moment it is needed.
>>>
>>> I propose to reverse this, and zero-initialize scalars in functions and
>>> structs.  For the cases where there is a performance impact, introduce a
>>> value std::uninitialized of type std::uninitialized_t, and define
>>> initialization of a scalar type from an std::uninitialized_t as the
>>> current behavior.
>>>
>>>
>> Other people have already commented about the performance impact of this
>> proposal. For me the biggest issue is another:
>> right now the compiler warns me if in a function I use a variable without
>> initializing it in some code path. If it was always initialized by default
>> to 0 and code started relying on this behaviour,  compilers would have to
>> stop issuing these useful warnings.
>>
>> -- gpd
>>
>
> I've seen that objection before, but if you truly believe that, why should
> it only apply to primitive types and aggregates containing them? Do you
> write most of your classes without default constructors to force users to
> explicitly initialize them?
>

.... If you don't give a class a default constructor, and that class has
other constructors, then that class *cannot* be default constructed. And
yes, that is a perfectly valid design choice.


> Would you argue that it would be better if std::string and the containers
> didn't have default constructors so compilers would warn if you didn't
> provide an explicit initialization?
>

Again, that is not what would happen. You'd get a hard compile error, not a
warning.


> How about the fact that all containers are specified to value-initialize
> their members, so std::vector<int>(10) gives you an array of 10 zeros and
> map_of_counters[some_key]++ works correctly even if some_key isn't in the
> map yet?
>

I agree with value initialization by default for containers. What I do not
agree with is changing code behind people's back. If it was uninitialized
before, then it should stay uninitialized.

Would this proposal be more palatable if phrased as "make
> value-construction the default and default-construction the exception"?
>

No. It still breaks tons of existing code by fundamentally changing its
behavior.

If this were the days of C or earlier, maybe I'd be willing to consider it.
But that time has *long since* passed. If you want
value-initialization-by-default, then you need a new language.

It is already how things work in containers and you need to go through a
> lot more effort than using something like std::uninitialized to make them
> default construct instead. It is also already the case that
> std::make_unique can only do value initialization and is incapable of
> default construction and many projects are using it instead of bare uses of
> new.
>
> Alternatively, how would you feel about an additional set of primitive
> types that provided value initialization semantics?
>

No. We don't need a bunch more scalar types.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ea05ac2c-8ce8-4384-b6eb-542d20bb5434%40isocpp.org.

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

<div dir=3D"ltr">On Friday, January 6, 2017 at 6:41:32 PM UTC-5, Mathias St=
earn wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
 Friday, January 6, 2017 at 10:45:41 AM UTC-5, Giovanni Piero Deretta wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Janu=
ary 5, 2017 at 8:33:44 AM UTC, Avi Kivity wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">Back in the day, the C decision to not initialize variables im=
plicitly=20
<br>made sense. =C2=A0Processors were slow, and optimizers weren&#39;t able=
 to=20
<br>identify and remove redundant assignments. =C2=A0These days however it&=
#39;s a=20
<br>source of bugs, and we have tools like placement new to delay=20
<br>initialization until the moment it is needed.
<br>
<br>I propose to reverse this, and zero-initialize scalars in functions and=
=20
<br>structs. =C2=A0For the cases where there is a performance impact, intro=
duce a=20
<br>value std::uninitialized of type std::uninitialized_t, and define=20
<br>initialization of a scalar type from an std::uninitialized_t as the=20
<br>current behavior.
<br>
<br></blockquote><div><br>Other people have already commented about the per=
formance impact of this proposal. For me the biggest issue is another:<br>r=
ight now the compiler warns me if in a function I use a variable without in=
itializing it in some code path. If it was always initialized by default to=
 0 and code started relying on this behaviour,=C2=A0 compilers would have t=
o stop issuing these useful warnings.<br><br>-- gpd<br></div></div></blockq=
uote><div><br></div><div>I&#39;ve seen that objection before, but if you tr=
uly believe that, why should it only apply to primitive types and aggregate=
s containing them? Do you write most of your classes without default constr=
uctors to force users to explicitly initialize them?</div></div></blockquot=
e><div><br>... If you don&#39;t give a class a default constructor, and tha=
t class has other constructors, then that class <i>cannot</i> be default co=
nstructed. And yes, that is a perfectly valid design choice.<br>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> Would =
you argue that it would be better if std::string and the containers didn&#3=
9;t have default constructors so compilers would warn if you didn&#39;t pro=
vide an explicit initialization?</div></div></blockquote><div><br>Again, th=
at is not what would happen. You&#39;d get a hard compile error, not a warn=
ing.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>How about the fact that all containers are specified to value=
-initialize their members, so std::vector&lt;int&gt;(10) gives you an array=
 of 10 zeros and map_of_counters[some_key]++ works correctly even if some_k=
ey isn&#39;t in the map yet?</div></div></blockquote><div><br>I agree with =
value initialization by default for containers. What I do not agree with is=
 changing code behind people&#39;s back. If it was uninitialized before, th=
en it should stay uninitialized.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Would this proposal=
 be more palatable if phrased as &quot;make value-construction the default =
and default-construction the exception&quot;?</div></div></blockquote><div>=
<br>No. It still breaks tons of existing code by fundamentally changing its=
 behavior.<br><br>If this were the days of C or earlier, maybe I&#39;d be w=
illing to consider it. But that time has <i>long since</i> passed. If you w=
ant value-initialization-by-default, then you need a new language.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It =
is already how things work in containers and you need to go through a lot m=
ore effort than using something like std::uninitialized to make them defaul=
t construct instead. It is also already the case that std::make_unique can =
only do value initialization and is incapable of default construction and m=
any projects are using it instead of bare uses of new.</div><div><br></div>=
<div>Alternatively, how would you feel about an additional set of primitive=
 types that provided value initialization semantics?</div></div></blockquot=
e><div><br>No. We don&#39;t need a bunch more scalar types.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea05ac2c-8ce8-4384-b6eb-542d20bb5434%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea05ac2c-8ce8-4384-b6eb-542d20bb5434=
%40isocpp.org</a>.<br />

------=_Part_393_235413202.1483748496400--

------=_Part_392_1539831339.1483748496399--

.

On sexta-feira, 6 de janeiro de 2017 07:17:53 PST Nicol Bolas wrote:
> No, it isn't. That constructor is user-provided. It is user-declared and
> not defaulted/deleted on its first declaration.

I stand corrected.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2617210.Gc5WAQLsuK%40tjmaciei-mobl1.

.

On 01/07/2017 12:50 AM, Richard Smith wrote:

> The fact that you can't resize a string or vector without initializing
> its elements is a measurable and significant performance problem for
> some applications; I have seen people invent their own string type or do

A std::uninitialized_t tag would enable us to provide uninitialized
resizing for those containers. Something like this:

   my_vector.resize(42, std::uninitialized_t);

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c803be62-0b0e-4479-8e9f-20b4f92a8002%40mail1.stofanet.dk.

.

On 2017-01-07 13:49, Bjorn Reese wrote:
> On 01/07/2017 12:50 AM, Richard Smith wrote:
>
>> The fact that you can't resize a string or vector without initializing
>> its elements is a measurable and significant performance problem for
>> some applications; I have seen people invent their own string type or do
>
> A std::uninitialized_t tag would enable us to provide uninitialized
> resizing for those containers. Something like this:
>
>   my_vector.resize(42, std::uninitialized_t);
>

This would allow as to easily create a std::vector with an invalid
state. Not something I have particularly missed in the current language.
  :-)


     Bo Persson


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/o4qoa3%24d0q%241%40blaine.gmane.org.

.

--f403045cef527fe262054580dd40
Content-Type: text/plain; charset=UTF-8

Nicol's proposal for std::default_init_t to address the container cases
should be on the first page or 2 of the list. That has the opposite
intention, of course! And for that reason, it's a good idea. ;)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFOJ1wB5N%2BV3Bws9WCVoRyeLY538YQXOv1oXtNrh8d7wA%40mail.gmail.com.

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

<div dir=3D"ltr">Nicol&#39;s proposal for std::default_init_t to address th=
e container cases should be on the first page or 2 of the list. That has th=
e opposite intention, of course! And for that reason, it&#39;s a good idea.=
 ;)<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFOJ1wB5N%2BV3Bws9WCVoRyeLY538Y=
QXOv1oXtNrh8d7wA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFOJ1wB5N=
%2BV3Bws9WCVoRyeLY538YQXOv1oXtNrh8d7wA%40mail.gmail.com</a>.<br />

--f403045cef527fe262054580dd40--

.

Em s=C3=A1bado, 7 de janeiro de 2017, =C3=A0s 13:49:56 PST, Bjorn Reese esc=
reveu:
> A std::uninitialized_t tag would enable us to provide uninitialized
> resizing for those containers. Something like this:
>=20
>    my_vector.resize(42, std::uninitialized_t);

The above doesn't need a language change. It can be implemented now.

In fact, I had this for QVector, but had to drop recently.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6034343.3DO7lIMXRM%40tjmaciei-mobl1.

.

--94eb2c07d8f68a23d0054590e7bb
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 9:19 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2017-01-05 19:54, Arthur O'Dwyer wrote:
>
> > In fact, wouldn't standardizing "zero by default" mean that no
> constructor
>
> > could ever be trivial, unless it was the constructor of an empty class?
>
>
>
> I think that, if such a feature were to ever happen (whether in the
>
> language or as a compiler option or whatever), it would be implemented
>
> by requiring whoever *reserves memory* to zero-initialize. IOW, `new`
>
> would ultimately call `calloc` instead of `malloc` (or something
>
> equivalent to that idea), and adjustment of the stack pointer to
>
> "allocate" on the stack would be followed by zeroing out that memory.
>
> This would happen *prior* to an object being constructed in said memory,
>
> so constructors could still be trivial.
>

>
> Following this comment, here's a thought about an alternate solution that
> may satisfy the goals of the OP.


> One currently can overload the operator new to forcefully initialize the
> memory for heap-allocated objects. For stack objects, this solution can be
> used:
> http://stackoverflow.com/questions/472015/new-on-stack-instead-of-heap-like-alloca-vs-malloc


> What about having an additional overload of the operator new for value
> (stack) objects instead?


> Zero initialization would be opt-in for heap and stack independently.


>
>
> On 2017-01-06 01:02, Nicol Bolas wrote:
>
> > After all, even invoking a trivial default constructor can still have an
>
> > observable effect: if the object is static or global, it will be
>
> > zero-initialized, despite the use of a trivial default constructor.
>
>
>
> ...but this likewise happens because the entire address space for static
>
> storage is zero initialized. The initialization isn't done by
>
> constructors, for individual objects, it's done for the whole address
>
> space (I believe all at once).
>
>
>
> --
>
> Matthew
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
>
> To post to this group, send email to std-proposals@isocpp.org.
>
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/586FB582.2010106%40gmail.com
> .
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMQec%2BYFLR%2BNyeYqqQ4Wt1cyd1Z4KeGBh4yoVcQD4yCHA%40mail.gmail.com.

--94eb2c07d8f68a23d0054590e7bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div><br><div class=3D"gmail_quote"><div>On Fri, Jan 6, 2017 at 9:19 AM Mat=
thew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-=
01-05 19:54, Arthur O&#39;Dwyer wrote:<br class=3D"gmail_msg"><br>&gt; In f=
act, wouldn&#39;t standardizing &quot;zero by default&quot; mean that no co=
nstructor<br class=3D"gmail_msg"><br>&gt; could ever be trivial, unless it =
was the constructor of an empty class?<br class=3D"gmail_msg"><br><br class=
=3D"gmail_msg"><br>I think that, if such a feature were to ever happen (whe=
ther in the<br class=3D"gmail_msg"><br>language or as a compiler option or =
whatever), it would be implemented<br class=3D"gmail_msg"><br>by requiring =
whoever *reserves memory* to zero-initialize. IOW, `new`<br class=3D"gmail_=
msg"><br>would ultimately call `calloc` instead of `malloc` (or something<b=
r class=3D"gmail_msg"><br>equivalent to that idea), and adjustment of the s=
tack pointer to<br class=3D"gmail_msg"><br>&quot;allocate&quot; on the stac=
k would be followed by zeroing out that memory.<br class=3D"gmail_msg"><br>=
This would happen *prior* to an object being constructed in said memory,<br=
 class=3D"gmail_msg"><br>so constructors could still be trivial.<br></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><br class=3D"gmail_msg"><br>Following =
this comment, here&#39;s a thought about an alternate solution that may sat=
isfy the goals of the OP.</blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">One currently can overload the op=
erator new to forcefully initialize the memory for heap-allocated objects. =
For stack objects, this solution can be used: <a href=3D"http://stackoverfl=
ow.com/questions/472015/new-on-stack-instead-of-heap-like-alloca-vs-malloc"=
>http://stackoverflow.com/questions/472015/new-on-stack-instead-of-heap-lik=
e-alloca-vs-malloc</a></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">What about having an additional ove=
rload of the operator new for value (stack) objects instead?</blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><br></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Zero initialization would be opt-in for heap and stack independently.</bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br><br>On 2017-01-06 01:02, Nicol Bolas wrote:<br class=3D"g=
mail_msg"><br>&gt; After all, even invoking a trivial default constructor c=
an still have an<br class=3D"gmail_msg"><br>&gt; observable effect: if the =
object is static or global, it will be<br class=3D"gmail_msg"><br>&gt; zero=
-initialized, despite the use of a trivial default constructor.<br class=3D=
"gmail_msg"><br><br class=3D"gmail_msg"><br>...but this likewise happens be=
cause the entire address space for static<br class=3D"gmail_msg"><br>storag=
e is zero initialized. The initialization isn&#39;t done by<br class=3D"gma=
il_msg"><br>constructors, for individual objects, it&#39;s done for the who=
le address<br class=3D"gmail_msg"><br>space (I believe all at once).<br cla=
ss=3D"gmail_msg"><br><br class=3D"gmail_msg"><br>--<br class=3D"gmail_msg">=
<br>Matthew<br class=3D"gmail_msg"><br><br class=3D"gmail_msg"><br>--<br cl=
ass=3D"gmail_msg"><br>You received this message because you are subscribed =
to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.=
<br class=3D"gmail_msg"><br>To unsubscribe from this group and stop receivi=
ng emails from it, send an email to <a href=3D"mailto:std-proposals%2Bunsub=
scribe@isocpp.org" class=3D"gmail_msg" target=3D"_blank">std-proposals+unsu=
bscribe@isocpp.org</a>.<br class=3D"gmail_msg"><br>To post to this group, s=
end email to <a href=3D"mailto:std-proposals@isocpp.org" class=3D"gmail_msg=
" target=3D"_blank">std-proposals@isocpp.org</a>.<br class=3D"gmail_msg"><b=
r>To view this discussion on the web visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/586FB582.2010106%40gmail.com" rel=
=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/586FB582.2010106%40gmail.com</a>.<b=
r class=3D"gmail_msg"><br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMQec%2BYFLR%2BNyeYqqQ4Wt1cyd=
1Z4KeGBh4yoVcQD4yCHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMQ=
ec%2BYFLR%2BNyeYqqQ4Wt1cyd1Z4KeGBh4yoVcQD4yCHA%40mail.gmail.com</a>.<br />

--94eb2c07d8f68a23d0054590e7bb--

.

On 2017-01-06 18:50, Richard Smith wrote:
> The fact that you can't resize a string or vector without initializing its
> elements is a measurable and significant performance problem for some
> applications; I have seen people invent their own string type or do truly
> horrible things to std::string (directly poking at its internals) to
> circumvent that.

Um... why do you need to do that? Why not reserve() the space you need
and append data? Is the cost of adjusting the size more than once really
so terrible to justify the loss of safety that comes from allowing the
vector/string to be, even temporarily, in an invalid state?

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5873B933.4060006%40gmail.com.

.

------=_Part_583_1425343972.1483982399545
Content-Type: multipart/alternative;
 boundary="----=_Part_584_727337713.1483982399545"

------=_Part_584_727337713.1483982399545
Content-Type: text/plain; charset=UTF-8



On Monday, January 9, 2017 at 11:24:22 AM UTC-5, Matthew Woehlke wrote:
>
> On 2017-01-06 18:50, Richard Smith wrote:
> > The fact that you can't resize a string or vector without initializing
> its
> > elements is a measurable and significant performance problem for some
> > applications; I have seen people invent their own string type or do
> truly
> > horrible things to std::string (directly poking at its internals) to
> > circumvent that.
>
> Um... why do you need to do that? Why not reserve() the space you need
> and append data? Is the cost of adjusting the size more than once really
> so terrible to justify the loss of safety that comes from allowing the
> vector/string to be, even temporarily, in an invalid state?
>

.... Yes, it is.

As I put forth in another thread, the ability to initialize such containers
via default initialization is important. There are many APIs that don't
work with C++ iterators. They only work with arrays in memory. Even
something like `istream::read` doesn't work that way.

And even for APIs that can handle C++ iterators, using the common
`reserve`+back-insertion trick results in sub-optimal code. The
back-insertion is constantly checking to see if it exceeds a size that the
higher-level code ensures will never be exceeded. Not to mention, you can't
do a `memcpy` to just blast data directly into that memory; it has to be
done one-by-one.

So long as default initialization is not the *default*, I see no reason why
standard library containers should explicitly *forbid* it. We gain safety
by requiring people to express their intent to use default initialization.
But once that intent is expressed, we should allow people to write code
whose safety is determined by a higher level.

People should not have to pay for what they don't use, right?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f7efcf66-7e91-4677-a059-8b24e86b034e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 9, 2017 at 11:24:22 AM UTC-5, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-0=
1-06 18:50, Richard Smith wrote:
<br>&gt; The fact that you can&#39;t resize a string or vector without init=
ializing its
<br>&gt; elements is a measurable and significant performance problem for s=
ome
<br>&gt; applications; I have seen people invent their own string type or d=
o truly
<br>&gt; horrible things to std::string (directly poking at its internals) =
to
<br>&gt; circumvent that.
<br>
<br>Um... why do you need to do that? Why not reserve() the space you need
<br>and append data? Is the cost of adjusting the size more than once reall=
y
<br>so terrible to justify the loss of safety that comes from allowing the
<br>vector/string to be, even temporarily, in an invalid state?<br></blockq=
uote><div><br>... Yes, it is.<br><br>As I put forth in another thread, the =
ability to initialize such containers via default initialization is importa=
nt. There are many APIs that don&#39;t work with C++ iterators. They only w=
ork with arrays in memory. Even something like `istream::read` doesn&#39;t =
work that way.<br><br>And even for APIs that can handle C++ iterators, usin=
g the common `reserve`+back-insertion trick results in sub-optimal code. Th=
e back-insertion is constantly checking to see if it exceeds a size that th=
e higher-level code ensures will never be exceeded. Not to mention, you can=
&#39;t do a `memcpy` to just blast data directly into that memory; it has t=
o be done one-by-one.<br><br>So long as default initialization is not the <=
i>default</i>, I see no reason why standard library containers should expli=
citly <i>forbid</i> it. We gain safety by requiring people to express their=
 intent to use default initialization. But once that intent is expressed, w=
e should allow people to write code whose safety is determined by a higher =
level.<br><br>People should not have to pay for what they don&#39;t use, ri=
ght?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f7efcf66-7e91-4677-a059-8b24e86b034e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7efcf66-7e91-4677-a059-8b24e86b034e=
%40isocpp.org</a>.<br />

------=_Part_584_727337713.1483982399545--

------=_Part_583_1425343972.1483982399545--

.

------=_Part_1162_606594285.1483995110506
Content-Type: multipart/alternative;
 boundary="----=_Part_1163_873463578.1483995110506"

------=_Part_1163_873463578.1483995110506
Content-Type: text/plain; charset=UTF-8



On Friday, January 6, 2017 at 9:19:32 AM UTC-6, Matthew Woehlke wrote:
>
> On 2017-01-05 19:54, Arthur O'Dwyer wrote:
> > In fact, wouldn't standardizing "zero by default" mean that no
> constructor
> > could ever be trivial, unless it was the constructor of an empty class?
>
> I think that, if such a feature were to ever happen (whether in the
> language or as a compiler option or whatever), it would be implemented
> by requiring whoever *reserves memory* to zero-initialize. IOW, `new`
> would ultimately call `calloc` instead of `malloc` (or something
> equivalent to that idea), and adjustment of the stack pointer to
> "allocate" on the stack would be followed by zeroing out that memory.
> This would happen *prior* to an object being constructed in said memory,
> so constructors could still be trivial.
>

It was pointed out to me that my first post wasn't done properly so I'm
posting the idea again in case someone couldn't read it.

Following this comment (on whoever reserves memory), here's a thought about
an alternate solution that may satisfy the goals of the OP: being able to
initialize memory before construction.
Currently, one can easily overload the operator new to forcefully
initialize the memory for heap-allocated objects.
For stack objects, this solution (alloca + placement new) can be used:
http://stackoverflow.com/questions/472015/new-on-stack-instead-of-heap-like-alloca-vs-malloc

What about having an additional overload of the operator new for value
(stack) objects instead?
Zero-initialization would be opt-in for heap and stack independently.

Some additional thoughts on it that were not in my first post:
This facility could add a way to manipulate the stack pointer and have
other uses as well, such as:
- modify the amount of memory reserved for stack objects for adding
instrumentation data
- return a different address (not necessarily in the stack?)

I imagine that in some cases stack objects might have their addresses
determined during compile-time, so I'm not quite sure if that's feasible --
unless the solution is also a compile-time one.


> On 2017-01-06 01:02, Nicol Bolas wrote:
> > After all, even invoking a trivial default constructor can still have an
> > observable effect: if the object is static or global, it will be
> > zero-initialized, despite the use of a trivial default constructor.
>
> ...but this likewise happens because the entire address space for static
> storage is zero initialized. The initialization isn't done by
> constructors, for individual objects, it's done for the whole address
> space (I believe all at once).
>
> --
> Matthew
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9da81458-fe00-488d-9062-1c2bf3401e5b%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, January 6, 2017 at 9:19:32 AM UTC-6, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01=
-05 19:54, Arthur O&#39;Dwyer wrote:
<br>&gt; In fact, wouldn&#39;t standardizing &quot;zero by default&quot; me=
an that no constructor=20
<br>&gt; could ever be trivial, unless it was the constructor of an empty c=
lass?
<br>
<br>I think that, if such a feature were to ever happen (whether in the
<br>language or as a compiler option or whatever), it would be implemented
<br>by requiring whoever *reserves memory* to zero-initialize. IOW, `new`
<br>would ultimately call `calloc` instead of `malloc` (or something
<br>equivalent to that idea), and adjustment of the stack pointer to
<br>&quot;allocate&quot; on the stack would be followed by zeroing out that=
 memory.
<br>This would happen *prior* to an object being constructed in said memory=
,
<br>so constructors could still be trivial.=C2=A0<br></blockquote><div><br>=
</div><div>It was pointed out to me that my first post wasn&#39;t done prop=
erly so I&#39;m posting the idea again in case someone couldn&#39;t read it=
..</div><div><br></div><div><div>Following this comment (on whoever reserves=
 memory), here&#39;s a thought about an alternate solution that may satisfy=
 the goals of the OP: being able to initialize memory before construction.<=
/div><div>Currently, one can easily overload the operator new to forcefully=
 initialize the memory for heap-allocated objects.<br>For stack objects, th=
is solution (alloca + placement new) can be used: http://stackoverflow.com/=
questions/472015/new-on-stack-instead-of-heap-like-alloca-vs-malloc</div><d=
iv><br></div><div>What about having an additional overload of the operator =
new for value (stack) objects instead?<br></div><div>Zero-initialization wo=
uld be opt-in for heap and stack independently.</div></div><div><br></div><=
div>Some additional thoughts on it that were not in my first post:<br></div=
><div>This facility could add a way to manipulate the stack pointer and hav=
e other uses as well, such as:<br></div><div>- modify the amount of memory =
reserved for stack objects for adding instrumentation data</div><div>- retu=
rn a different address (not necessarily in the stack?)</div><div><br></div>=
<div>I imagine that in some cases stack objects might have their addresses =
determined during compile-time, so I&#39;m not quite sure if that&#39;s fea=
sible -- unless the solution is also a compile-time one.</div><div>=C2=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-06 01:02, N=
icol Bolas wrote:
<br>&gt; After all, even invoking a trivial default constructor can still h=
ave an=20
<br>&gt; observable effect: if the object is static or global, it will be=
=20
<br>&gt; zero-initialized, despite the use of a trivial default constructor=
..
<br>
<br>...but this likewise happens because the entire address space for stati=
c
<br>storage is zero initialized. The initialization isn&#39;t done by
<br>constructors, for individual objects, it&#39;s done for the whole addre=
ss
<br>space (I believe all at once).
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9da81458-fe00-488d-9062-1c2bf3401e5b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9da81458-fe00-488d-9062-1c2bf3401e5b=
%40isocpp.org</a>.<br />

------=_Part_1163_873463578.1483995110506--

------=_Part_1162_606594285.1483995110506--

.

On segunda-feira, 9 de janeiro de 2017 12:51:50 PST Ricardo Andrade wrote:
> Following this comment (on whoever reserves memory), here's a thought about
> an alternate solution that may satisfy the goals of the OP: being able to
> initialize memory before construction.

We've had this discussion too. There's no need to pre-initialise memory.

If the type in question has a trivial constructor, then any value you store in
memory is a valid state. Moreover, allocation of memory is the beginning of
the object's lifetime. If you want to memset the region after creation or if
your container does it for you, you can. For trivially constructible types, it
makes sense to have std::uninitialized_t, but that's a library solution, not a
core language change.

If the type in question has a non-trivial constructor, then it's completely
irrelevant what existed in memory before. The compiler is allowed to use it as
scratch space until user code stores a value there.

> Some additional thoughts on it that were not in my first post:
> This facility could add a way to manipulate the stack pointer and have
> other uses as well, such as:
> - modify the amount of memory reserved for stack objects for adding
> instrumentation data
> - return a different address (not necessarily in the stack?)

That's really, REALLY platform-specific. You really ought to make this work
with compiler builtins/intrinsics in some platform and show it works. Then
make it work on a couple more (including platforms like Itanium that have two
stack pointers). Only then should this become a discussion for the standards
committee.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1886999.jHOh09sLQ9%40tjmaciei-mobl1.

.

--001a1148f9f0dfc81f0545afd63c
Content-Type: text/plain; charset=UTF-8

On 9 January 2017 at 08:24, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2017-01-06 18:50, Richard Smith wrote:
> > The fact that you can't resize a string or vector without initializing
> its
> > elements is a measurable and significant performance problem for some
> > applications; I have seen people invent their own string type or do truly
> > horrible things to std::string (directly poking at its internals) to
> > circumvent that.
>
> Um... why do you need to do that? Why not reserve() the space you need
> and append data? Is the cost of adjusting the size more than once really
> so terrible to justify the loss of safety that comes from allowing the
> vector/string to be, even temporarily, in an invalid state?


Actually, it turns out, yes, that is sometimes the pragmatic engineering
tradeoff.

Consider the case where you are passing the string as a buffer to a C-style
interface that takes (char *buffer, size_t max_length), and returns the
length it actually wrote. It's not enough to just reserve() first, and if
you resize() first you've done redundant zero-filling. And you can't put
the data into a structure of a different kind because your API and ABI
require you to produce a std::string, and you can't put it somewhere
temporary and make a copy because this is on the hottest path in an
application that will be running on many thousands of cores.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqk%2BEc%2BVnHLCb5JTg%3DerGMsPXeJ47ga8Gx-hA9mpLWy8gw%40mail.gmail.com.

--001a1148f9f0dfc81f0545afd63c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 9=
 January 2017 at 08:24, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
2017-01-06 18:50, Richard Smith wrote:<br>
&gt; The fact that you can&#39;t resize a string or vector without initiali=
zing its<br>
&gt; elements is a measurable and significant performance problem for some<=
br>
&gt; applications; I have seen people invent their own string type or do tr=
uly<br>
&gt; horrible things to std::string (directly poking at its internals) to<b=
r>
&gt; circumvent that.<br>
<br>
</span>Um... why do you need to do that? Why not reserve() the space you ne=
ed<br>
and append data? Is the cost of adjusting the size more than once really<br=
>
so terrible to justify the loss of safety that comes from allowing the<br>
vector/string to be, even temporarily, in an invalid state?</blockquote><di=
v><br></div><div>Actually, it turns out, yes, that is sometimes the pragmat=
ic engineering tradeoff.</div><div><br></div><div>Consider the case where y=
ou are passing the string as a buffer to a C-style interface that takes (ch=
ar *buffer, size_t max_length), and returns the length it actually wrote. I=
t&#39;s not enough to just reserve() first, and if you resize() first you&#=
39;ve done redundant zero-filling. And you can&#39;t put the data into a st=
ructure of a different kind because your API and ABI require you to produce=
 a std::string, and you can&#39;t put it somewhere temporary and make a cop=
y because this is on the hottest path in an application that will be runnin=
g on many thousands of cores.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqk%2BEc%2BVnHLCb5JTg%3DerGMsPXe=
J47ga8Gx-hA9mpLWy8gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqk%2B=
Ec%2BVnHLCb5JTg%3DerGMsPXeJ47ga8Gx-hA9mpLWy8gw%40mail.gmail.com</a>.<br />

--001a1148f9f0dfc81f0545afd63c--

.

------=_Part_1090_1448088620.1483996680308
Content-Type: multipart/alternative;
 boundary="----=_Part_1091_710699181.1483996680308"

------=_Part_1091_710699181.1483996680308
Content-Type: text/plain; charset=UTF-8


>
>
> The fact that you can't resize a string or vector without initializing its
> elements is a measurable and significant performance problem for some
> applications; I have seen people invent their own string type or do truly
> horrible things to std::string (directly poking at its internals) to
> circumvent that.
>
>
So this. So why can't we fix this?

Can't we have uninitialized_resize() etc. to stop this?

There is a lot of code that wants to call C api's to populate string
objects and they do this:

char* do_something_for_c_library()
{
std::string s;
s.resize(n+1);
len = SomeCAPI(s.data(), n)
s.resize(len)
s += "hello";

char* ptr = malloc(s.length()+1);
if (!ptr) return nullptr;
strcpy(ptr, some_other_data, s.length());
ptr[s.length()]='\0';
return otr;
}

They want string because it's useful for string things while in the
function.
They also want string because if there's an exception  the destructor will
release the memory.
They also want string for an small buffer optimization.

Why can't we enable this for these people:
char* do_something_for_c_library()
{
std::string s;
s.uninitialized_resize(n+1);
len = SomeCAPI(s.data(),n)
s.resize(n);
s+="hello";

char* ptr = s.detach(std::nullterminate);
return ptr;
}

// detach means:
// Give me the memory, copy if needed (e.g. for sso),
// ensure it's null terminated.
 return null if there's a problem with any of that and leave s as it was.
// otherwise give me the ptr and leave string empty()

return ptr;
}

This for vector too.

At least unitialized_resize().

Why not?

Thanks

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c0e0da71-0361-431c-b227-87bd7727f686%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div><br></div><div>The fact that you can&#39;t resize =
a string or vector without initializing its elements is a measurable and si=
gnificant performance problem for some applications; I have seen people inv=
ent their own string type or do truly horrible things to std::string (direc=
tly poking at its internals) to circumvent that.</div><div><br></div></div>=
</div></div></blockquote><div><br></div><div>So this. So why can&#39;t we f=
ix this?</div><div><br></div><div><div>Can&#39;t we have uninitialized_resi=
ze() etc. to stop this?</div><div><br></div></div><div>There is a lot of co=
de that wants to call C api&#39;s to populate string objects and they do th=
is:</div><div><br></div><div>char* do_something_for_c_library()</div><div>{=
</div><div>std::string s;</div><div>s.resize(n+1);</div><div>len =3D SomeCA=
PI(s.data(), n)</div><div>s.resize(len)</div><div>s +=3D &quot;hello&quot;;=
</div><div><br></div><div>char* ptr =3D malloc(s.length()+1);</div><div>if =
(!ptr) return nullptr;</div><div>strcpy(ptr, some_other_data, s.length());<=
/div><div>ptr[s.length()]=3D&#39;\0&#39;;</div><div>return otr;</div><div>}=
</div><div><br></div><div>They want string because it&#39;s useful for stri=
ng things while in the function.</div><div>They also want string because if=
 there&#39;s an exception=C2=A0 the destructor will release the memory.</di=
v><div>They also want string for an small buffer optimization.</div><div><b=
r></div><div>Why can&#39;t we enable this for these people:</div><div><div>=
char* do_something_for_c_library()</div><div>{</div><div>std::string s;</di=
v><div>s.uninitialized_resize(n+1);</div><div>len =3D SomeCAPI(s.data(),n)<=
/div></div><div>s.resize(n);</div><div>s+=3D&quot;hello&quot;;</div><div><b=
r></div><div>char* ptr =3D s.detach(std::nullterminate); </div><div>return =
ptr;</div><div>}</div><div><br></div><div>// detach means:</div><div>// Giv=
e me the memory, copy if needed (e.g. for sso),</div><div>// ensure it&#39;=
s null terminated.</div><div>=C2=A0return null if there&#39;s a problem wit=
h any of that and leave s as it was.</div><div>//=C2=A0otherwise give me th=
e ptr and=C2=A0leave string empty()</div><div><br></div><div>return ptr;</d=
iv><div>}</div><div><br></div><div>This for vector too.</div><div><br></div=
><div>At least unitialized_resize().</div><div><br></div><div>Why not?</div=
><div><br></div><div>Thanks</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c0e0da71-0361-431c-b227-87bd7727f686%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0e0da71-0361-431c-b227-87bd7727f686=
%40isocpp.org</a>.<br />

------=_Part_1091_710699181.1483996680308--

------=_Part_1090_1448088620.1483996680308--

.

------=_Part_1285_355084087.1483997467762
Content-Type: multipart/alternative;
 boundary="----=_Part_1286_1994561913.1483997467762"

------=_Part_1286_1994561913.1483997467762
Content-Type: text/plain; charset=UTF-8



On Monday, January 9, 2017 at 4:18:00 PM UTC-5, gmis...@gmail.com wrote:
>
>
>> The fact that you can't resize a string or vector without initializing
>> its elements is a measurable and significant performance problem for some
>> applications; I have seen people invent their own string type or do truly
>> horrible things to std::string (directly poking at its internals) to
>> circumvent that.
>>
>>
> So this. So why can't we fix this?
>

I would rather this be part of a generalized, comprehensive way of being
able to invoke default initialization on types
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ>.
Standard library containers should of course be extended to fit such syntax.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d64feb8e-cc87-4f6c-a80d-2267ac029db8%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 9, 2017 at 4:18:00 PM UTC-5, gm=
is...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<div><br></div><div>The fact that you can&#39;t resize a string or vector w=
ithout initializing its elements is a measurable and significant performanc=
e problem for some applications; I have seen people invent their own string=
 type or do truly horrible things to std::string (directly poking at its in=
ternals) to circumvent that.</div><div><br></div></div></div></div></blockq=
uote><div><br></div><div>So this. So why can&#39;t we fix this?</div></div>=
</blockquote><div><br>I would rather this be part of a <a href=3D"https://g=
roups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-pr=
oposals/54K4WTb4EcU/eJHx0rFECQAJ">generalized, comprehensive way of being a=
ble to invoke default initialization on types</a>. Standard library contain=
ers should of course be extended to fit such syntax.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d64feb8e-cc87-4f6c-a80d-2267ac029db8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d64feb8e-cc87-4f6c-a80d-2267ac029db8=
%40isocpp.org</a>.<br />

------=_Part_1286_1994561913.1483997467762--

------=_Part_1285_355084087.1483997467762--

.

------=_Part_4384_1605512006.1483998133150
Content-Type: multipart/alternative;
 boundary="----=_Part_4385_1925291607.1483998133150"

------=_Part_4385_1925291607.1483998133150
Content-Type: text/plain; charset=UTF-8


>
>
> I would rather this be part of a generalized, comprehensive way of being
> able to invoke default initialization on types
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ>.
> Standard library containers should of course be extended to fit such syntax.
>

Ok as long as default initialization means non initialization as that's
what I want here as far as I know.
{noinit};

Do we really need to wait for perfection though, just to get the two API's
I described?
If these basic API's squeezed in C++17 it might make some people who aren't
happy more happy!
I'm very happy with C+17 for what it's worth. But I'd dearly love these two
routines to be in it for string and vector.
It probably can't happen, but could it..

Any more details on your vision of this would be great. Are we likely to
get your vision? Has it progressed any further

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0eecffef-ec66-4787-9605-5b8776bd6009%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>I w=
ould rather this be part of a <a onmousedown=3D"this.href=3D&#39;https://gr=
oups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-pro=
posals/54K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/d=
efault/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;" href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default=
/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ" target=3D"_blank" rel=3D"nofollow"=
>generalized, comprehensive way of being able to invoke default initializat=
ion on types</a>. Standard library containers should of course be extended =
to fit such syntax.</div></div></blockquote><div><br></div><div>Ok as long =
as=C2=A0default initialization means=C2=A0non initialization as that&#39;s =
what I want here as far as I know.</div><div>{noinit};</div><div><br></div>=
<div>Do we really need to wait for perfection though, just to=C2=A0get the=
=C2=A0two API&#39;s I described?</div><div>If these basic API&#39;s squeeze=
d in C++17 it might make some people who aren&#39;t happy more happy!</div>=
<div>I&#39;m very happy with C+17 for what it&#39;s worth. But I&#39;d dear=
ly love these two routines to be in it for string and vector.</div><div>It =
probably can&#39;t happen, but could it..</div><div><br></div><div>Any more=
 details on=C2=A0your vision=C2=A0of this would be great. Are we likely to =
get your vision? Has it progressed any further</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0eecffef-ec66-4787-9605-5b8776bd6009%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0eecffef-ec66-4787-9605-5b8776bd6009=
%40isocpp.org</a>.<br />

------=_Part_4385_1925291607.1483998133150--

------=_Part_4384_1605512006.1483998133150--

.

------=_Part_1159_599933031.1483998523469
Content-Type: multipart/alternative;
 boundary="----=_Part_1160_818342335.1483998523470"

------=_Part_1160_818342335.1483998523470
Content-Type: text/plain; charset=UTF-8



On Tuesday, January 10, 2017 at 10:31:07 AM UTC+13, Nicol Bolas wrote:
>
>
>
> On Monday, January 9, 2017 at 4:18:00 PM UTC-5, gmis...@gmail.com wrote:
>>
>>
>>> The fact that you can't resize a string or vector without initializing
>>> its elements is a measurable and significant performance problem for some
>>> applications; I have seen people invent their own string type or do truly
>>> horrible things to std::string (directly poking at its internals) to
>>> circumvent that.
>>>
>>>
>> So this. So why can't we fix this?
>>
>
> I would rather this be part of a generalized, comprehensive way of being
> able to invoke default initialization on types
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ>.
> Standard library containers should of course be extended to fit such syntax.
>


We seem to have a situation where C is in free-fall decline (at least on
the tiobe index).
If we can do more to support C programmers moving over to C++ it would be
win win.
Maybe making these kind of interop performance tuning optimizations might
help that.
But I'd love them sooner than later. I think the last change I suggested
alone would enable some massive performance wins in places were it
possible, so I'd love to know how hard providing those two API's mentioned
in my last post really are to get.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/98bf8c96-abc5-49a3-8c79-62af5d546f67%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 10, 2017 at 10:31:07 AM UTC+13=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><br>O=
n Monday, January 9, 2017 at 4:18:00 PM UTC-5, <a>gmis...@gmail.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail=
_quote" 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=
;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>The=
 fact that you can&#39;t resize a string or vector without initializing its=
 elements is a measurable and significant performance problem for some appl=
ications; I have seen people invent their own string type or do truly horri=
ble things to std::string (directly poking at its internals) to circumvent =
that.</div><div><br></div></div></div></div></blockquote><div><br></div><di=
v>So this. So why can&#39;t we fix this?</div></div></blockquote><div><br>I=
 would rather this be part of a <a onmousedown=3D"this.href=3D&#39;https://=
groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-p=
roposals/54K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposa=
ls/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;" href=
=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/d=
efault/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ" target=3D"_blank" rel=3D"nof=
ollow">generalized, comprehensive way of being able to invoke default initi=
alization on types</a>. Standard library containers should of course be ext=
ended to fit such syntax.</div></div></blockquote><div><br></div><div><br><=
/div><div>We=C2=A0seem to have a situation=C2=A0where C=C2=A0is in free-fal=
l decline (at least on the tiobe index).</div><div>If we can do more to sup=
port C programmers moving over to C++ it would be win win.</div><div>Maybe =
making these kind of interop=C2=A0performance tuning optimizations might he=
lp that.</div><div>But I&#39;d love them sooner than later. I think the las=
t change I suggested alone would enable=C2=A0some massive performance wins =
in places were=C2=A0it possible, so I&#39;d love to know how hard providing=
 those two API&#39;s mentioned in my last post really are to get.</div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/98bf8c96-abc5-49a3-8c79-62af5d546f67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98bf8c96-abc5-49a3-8c79-62af5d546f67=
%40isocpp.org</a>.<br />

------=_Part_1160_818342335.1483998523470--

------=_Part_1159_599933031.1483998523469--

.

--047d7b3a8c2c27867c0545b05a79
Content-Type: text/plain; charset=UTF-8

You're not going to get them in C++17, unless you happen to be a member of
a national body, assuming that window hasn't yet closed too.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHYawsvF%3DPkP0GBJXepqD66FSCPkbnx0Haaca%3Dt1v027Q%40mail.gmail.com.

--047d7b3a8c2c27867c0545b05a79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You&#39;re not going to get them in C++17, unless you happ=
en to be a member of a national body, assuming that window hasn&#39;t yet c=
losed too.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHYawsvF%3DPkP0GBJXepqD66FSCPkb=
nx0Haaca%3Dt1v027Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHYawsv=
F%3DPkP0GBJXepqD66FSCPkbnx0Haaca%3Dt1v027Q%40mail.gmail.com</a>.<br />

--047d7b3a8c2c27867c0545b05a79--

.

------=_Part_1206_422748358.1483999096031
Content-Type: multipart/alternative;
 boundary="----=_Part_1207_422203739.1483999096031"

------=_Part_1207_422203739.1483999096031
Content-Type: text/plain; charset=UTF-8



On Tuesday, January 10, 2017 at 10:50:14 AM UTC+13, D. B. wrote:
>
> You're not going to get them in C++17, unless you happen to be a member of
> a national body, assuming that window hasn't yet closed too.
>

vv you are our only hope lol

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dbb458fb-6141-4392-a53b-62ef126ac604%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 10, 2017 at 10:50:14 AM UTC+13=
, D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">You&#39;re not =
going to get them in C++17, unless you happen to be a member of a national =
body, assuming that window hasn&#39;t yet closed too.<br></div></blockquote=
><div><br></div><div>vv=C2=A0you are our only hope lol=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dbb458fb-6141-4392-a53b-62ef126ac604%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dbb458fb-6141-4392-a53b-62ef126ac604=
%40isocpp.org</a>.<br />

------=_Part_1207_422203739.1483999096031--

------=_Part_1206_422748358.1483999096031--

.

------=_Part_1259_1425677801.1484004599844
Content-Type: multipart/alternative;
 boundary="----=_Part_1260_1690723639.1484004599844"

------=_Part_1260_1690723639.1484004599844
Content-Type: text/plain; charset=UTF-8



On Monday, January 9, 2017 at 4:42:13 PM UTC-5, gmis...@gmail.com wrote:
>
>
>> I would rather this be part of a generalized, comprehensive way of being
>> able to invoke default initialization on types
>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ>.
>> Standard library containers should of course be extended to fit such syntax.
>>
>
> Ok as long as default initialization means non initialization as that's
> what I want here as far as I know.
>

No, it means default initialization, as defined by the standard. If the
type is a trivial type, then trivial default construction will take place,
which means nothing happens. So it only means "non-initialized" if the type
*permits* such a thing.


> {noinit};
>
> Do we really need to wait for perfection though, just to get the two API's
> I described?
> If these basic API's squeezed in C++17 it might make some people who
> aren't happy more happy!
>

But it would also be difficult to get the right functionality after the
fact. Why rush into a half-solution, when the whole-solution isn't that
much harder?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/85a9afe8-4f0c-4ede-b11d-e48e86390eef%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 9, 2017 at 4:42:13 PM UTC-5, gm=
is...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"><div><br>I would rather this be =
part of a <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchi=
n/std-proposals/default/std-proposals/54K4WTb4EcU/eJHx0rFECQAJ" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/forum/#!searchin/std-proposals/default/std-proposals/54=
K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https=
://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/default/st=
d-proposals/54K4WTb4EcU/eJHx0rFECQAJ&#39;;return true;">generalized, compre=
hensive way of being able to invoke default initialization on types</a>. St=
andard library containers should of course be extended to fit such syntax.<=
/div></div></blockquote><div><br></div><div>Ok as long as=C2=A0default init=
ialization means=C2=A0non initialization as that&#39;s what I want here as =
far as I know.</div></div></blockquote><div><br>No, it means default initia=
lization, as defined by the standard. If the type is a trivial type, then t=
rivial default construction will take place, which means nothing happens. S=
o it only means &quot;non-initialized&quot; if the type <i>permits</i> such=
 a thing.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>{noinit};</div><div><br></div><div>Do we really need to wa=
it for perfection though, just to=C2=A0get the=C2=A0two API&#39;s I describ=
ed?</div><div>If these basic API&#39;s squeezed in C++17 it might make some=
 people who aren&#39;t happy more happy!</div></div></blockquote><div><br>B=
ut it would also be difficult to get the right functionality after the fact=
.. Why rush into a half-solution, when the whole-solution isn&#39;t that muc=
h harder?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/85a9afe8-4f0c-4ede-b11d-e48e86390eef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/85a9afe8-4f0c-4ede-b11d-e48e86390eef=
%40isocpp.org</a>.<br />

------=_Part_1260_1690723639.1484004599844--

------=_Part_1259_1425677801.1484004599844--

.

On segunda-feira, 9 de janeiro de 2017 13:42:13 PST gmisocpp@gmail.com wrote:
> If these basic API's squeezed in C++17 it might make some people who aren't
> happy more happy!

Extremely unlikely. The draft has been approved, so I don't think anyone will
allow new features to be added. Defect correction and removing things that are
potentially dangerous could happen; adding overloads or other omissions by
mistake could happen, if they can be considered part of an existing feature
being added.

New features, forget it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1595136.k0e3EIzT4W%40tjmaciei-mobl1.

.

On 07/01/2017 14:10, D. B. wrote:
> Nicol's proposal for std::default_init_t to address the container cases
> should be on the first page or 2 of the list. That has the opposite
> intention, of course! And for that reason, it's a good idea. ;)

It's been requested several times. Boost implemented it as there was
user demand:

http://www.boost.org/doc/libs/1_63_0/doc/html/container/extended_functionality.html#container.extended_functionality.default_initialialization

Best,

Ion

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/82b458ff-bd3b-3d24-6e95-d756811708bd%40gmail.com.

.

------=_Part_6070_183009511.1484129770654
Content-Type: multipart/alternative;
 boundary="----=_Part_6071_1963446125.1484129770654"

------=_Part_6071_1963446125.1484129770654
Content-Type: text/plain; charset=UTF-8



On Tuesday, January 10, 2017 at 1:59:22 PM UTC+13, Thiago Macieira wrote:
>
> On segunda-feira, 9 de janeiro de 2017 13:42:13 PST gmis...@gmail.com
> <javascript:> wrote:
> > If these basic API's squeezed in C++17 it might make some people who
> aren't
> > happy more happy!
>
> Extremely unlikely. The draft has been approved, so I don't think anyone
> will
> allow new features to be added. Defect correction and removing things that
> are
> potentially dangerous could happen; adding overloads or other omissions by
> mistake could happen, if they can be considered part of an existing
> feature
> being added.
>
> New features, forget it.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
I assume you saw Ion posted this:

http://www.boost.org/doc/libs/1_63_0/doc/html/container/extended_functionality.html#container.extended_functionality.default_initialialization

Which looks very much what nicol proposed.

Airlift into C++17? Even just for vector/string?
Ducks runs for cover.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8cd7dd42-ccc8-4c3e-81d2-38c64a834d79%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 10, 2017 at 1:59:22 PM UTC+13,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;">On segunda-feira, 9 de =
janeiro de 2017 13:42:13 PST <a onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-=
mailto=3D"NWC5CyPDBQAJ">gmis...@gmail.com</a> wrote:
<br>&gt; If these basic API&#39;s squeezed in C++17 it might make some peop=
le who aren&#39;t
<br>&gt; happy more happy!
<br>
<br>Extremely unlikely. The draft has been approved, so I don&#39;t think a=
nyone will=20
<br>allow new features to be added. Defect correction and removing things t=
hat are=20
<br>potentially dangerous could happen; adding overloads or other omissions=
 by=20
<br>mistake could happen, if they can be considered part of an existing fea=
ture=20
<br>being added.
<br>
<br>New features, forget it.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I assume you saw Ion=C2=A0posted this:=
</div><div><br></div><div><a onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fh=
tml%2Fcontainer%2Fextended_functionality.html%23container.extended_function=
ality.default_initialialization\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVf=
cmIUif46BN-vAbIZTBDrvHyFg&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_63=
_0%2Fdoc%2Fhtml%2Fcontainer%2Fextended_functionality.html%23container.exten=
ded_functionality.default_initialialization\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGVfcmIUif46BN-vAbIZTBDrvHyFg&#39;;return true;" href=3D"http://www=
..boost.org/doc/libs/1_63_0/doc/html/container/extended_functionality.html#c=
ontainer.extended_functionality.default_initialialization" target=3D"_blank=
" rel=3D"nofollow">http://www.boost.org/doc/libs/<wbr>1_63_0/doc/html/conta=
iner/<wbr>extended_functionality.html#<wbr>container.extended_<wbr>function=
ality.default_<wbr>initialialization</a> </div><div><br></div><div>Which lo=
oks very much what nicol proposed.<br><br></div><div>Airlift=C2=A0into C++1=
7? Even just for vector/string?</div><div>Ducks runs for cover.</div><div>=
=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8cd7dd42-ccc8-4c3e-81d2-38c64a834d79%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8cd7dd42-ccc8-4c3e-81d2-38c64a834d79=
%40isocpp.org</a>.<br />

------=_Part_6071_1963446125.1484129770654--

------=_Part_6070_183009511.1484129770654--

.

------=_Part_6423_94247165.1484156052653
Content-Type: multipart/alternative;
 boundary="----=_Part_6424_432966035.1484156052653"

------=_Part_6424_432966035.1484156052653
Content-Type: text/plain; charset=UTF-8



On Wednesday, January 11, 2017 at 12:25:01 PM UTC-5, Thiago Macieira wrote:
>
> On quarta-feira, 11 de janeiro de 2017 02:16:10 PST gmis...@gmail.com
> <javascript:> wrote:
> > I assume you saw Ion posted this:
> >
> >
> http://www.boost.org/doc/libs/1_63_0/doc/html/container/extended_functionali
> > ty.html#container.extended_functionality.default_initialialization
>
> I assume you meant "you" in general, to mean everyone in the discussion.
> But
> since one person in particular (me) had not seen it, the answer is "no, we
> had
> not seen it" :-)
>
> [Why would I have seen anything in Boost? I don't use that library]
>

Because someone else posted that link
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_OCzjbBQAJ>and
we generally assume readers of threads have actually read it ;)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/52895752-72dd-4254-800d-566bcde0e6c8%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, January 11, 2017 at 12:25:01 PM UTC-=
5, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On qu=
arta-feira, 11 de janeiro de 2017 02:16:10 PST <a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"G8GMQIFHBgAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">gmis...@gmail.com</a> wrote:
<br>&gt; I assume you saw Ion posted this:
<br>&gt;=20
<br>&gt; <a href=3D"http://www.boost.org/doc/libs/1_63_0/doc/html/container=
/extended_functionali" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2F=
doc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%2Fextended_functionali\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3nMDdQTJKNe-SmN_wSkBS7P7Zpg&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fwww.boost.org%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%2Fextended_=
functionali\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3nMDdQTJKNe-SmN_wSkBS7=
P7Zpg&#39;;return true;">http://www.boost.org/doc/libs/<wbr>1_63_0/doc/html=
/container/<wbr>extended_functionali</a>
<br>&gt; ty.html#container.extended_<wbr>functionality.default_<wbr>initial=
ialization
<br>
<br>I assume you meant &quot;you&quot; in general, to mean everyone in the =
discussion. But=20
<br>since one person in particular (me) had not seen it, the answer is &quo=
t;no, we had=20
<br>not seen it&quot; :-)
<br>
<br>[Why would I have seen anything in Boost? I don&#39;t use that library]
<br></blockquote><div><br>Because <a href=3D"https://groups.google.com/a/is=
ocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_OCzjbBQAJ">someone else posted =
that link </a>and we generally assume readers of threads have actually read=
 it ;)</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/52895752-72dd-4254-800d-566bcde0e6c8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/52895752-72dd-4254-800d-566bcde0e6c8=
%40isocpp.org</a>.<br />

------=_Part_6424_432966035.1484156052653--

------=_Part_6423_94247165.1484156052653--

.

On quarta-feira, 11 de janeiro de 2017 09:34:12 PST Nicol Bolas wrote:
> Because someone else posted that link
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_O
> CzjbBQAJ>and we generally assume readers of threads have actually read it ;)

Oops, shame on me.

I usually do read entire threads, but some threads on this ML and in std-
discussion tend to blow out of proportion...

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2559930.DZQvY9VPoX%40tjmaciei-mobl1.

.

------=_Part_7004_428925847.1484169365761
Content-Type: multipart/alternative;
 boundary="----=_Part_7005_280056328.1484169365761"

------=_Part_7005_280056328.1484169365761
Content-Type: text/plain; charset=UTF-8



On Thursday, January 12, 2017 at 8:02:34 AM UTC+13, Thiago Macieira wrote:
>
> On quarta-feira, 11 de janeiro de 2017 09:34:12 PST Nicol Bolas wrote:
> > Because someone else posted that link
> > <
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_O
> > CzjbBQAJ>and we generally assume readers of threads have actually read
> it ;)
>
> Oops, shame on me.
>
> I usually do read entire threads, but some threads on this ML and in std-
> discussion tend to blow out of proportion...
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
Ha ha :)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f77e7424-0ea7-488f-bd7f-c83e9dcdf970%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 8:02:34 AM UTC+13=
, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" 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;">On quarta-feira, 11 de=
 janeiro de 2017 09:34:12 PST Nicol Bolas wrote:
<br>&gt; Because someone else posted that link
<br>&gt; &lt;<a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a=
/isocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_O&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/lh3kuj1qn8M/bQ_O&#39;;return true;" href=3D"https://groups.google.com/=
a/isocpp.org/d/msg/std-proposals/lh3kuj1qn8M/bQ_O" target=3D"_blank" rel=3D=
"nofollow">https://groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>propo=
sals/lh3kuj1qn8M/bQ_O</a>
<br>&gt; CzjbBQAJ&gt;and we generally assume readers of threads have actual=
ly read it ;)
<br>
<br>Oops, shame on me.
<br>
<br>I usually do read entire threads, but some threads on this ML and in st=
d-
<br>discussion tend to blow out of proportion...
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>Ha ha :)=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f77e7424-0ea7-488f-bd7f-c83e9dcdf970%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f77e7424-0ea7-488f-bd7f-c83e9dcdf970=
%40isocpp.org</a>.<br />

------=_Part_7005_280056328.1484169365761--

------=_Part_7004_428925847.1484169365761--

.

On quarta-feira, 11 de janeiro de 2017 02:16:10 PST gmisocpp@gmail.com wrote:
> I assume you saw Ion posted this:
>
> http://www.boost.org/doc/libs/1_63_0/doc/html/container/extended_functionali
> ty.html#container.extended_functionality.default_initialialization

I assume you meant "you" in general, to mean everyone in the discussion. But
since one person in particular (me) had not seen it, the answer is "no, we had
not seen it" :-)

[Why would I have seen anything in Boost? I don't use that library]

> Which looks very much what nicol proposed.
>
> Airlift into C++17? Even just for vector/string?
> Ducks runs for cover.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6223317.2bERTiFpuU%40tjmaciei-mobl1.

.

------=_Part_1205_727252079.1484560563939
Content-Type: multipart/alternative;
 boundary="----=_Part_1206_1979630076.1484560563939"

------=_Part_1206_1979630076.1484560563939
Content-Type: text/plain; charset=UTF-8



Op woensdag 11 januari 2017 11:16:10 UTC+1 schreef gmis...@gmail.com:
>
>
>
> On Tuesday, January 10, 2017 at 1:59:22 PM UTC+13, Thiago Macieira wrote:
>>
>> On segunda-feira, 9 de janeiro de 2017 13:42:13 PST gmis...@gmail.com
>> wrote:
>> > If these basic API's squeezed in C++17 it might make some people who
>> aren't
>> > happy more happy!
>>
>> Extremely unlikely. The draft has been approved, so I don't think anyone
>> will
>> allow new features to be added. Defect correction and removing things
>> that are
>> potentially dangerous could happen; adding overloads or other omissions
>> by
>> mistake could happen, if they can be considered part of an existing
>> feature
>> being added.
>>
>> New features, forget it.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>>
> I assume you saw Ion posted this:
>
>
> http://www.boost.org/doc/libs/1_63_0/doc/html/container/extended_functionality.html#container.extended_functionality.default_initialialization
>
> Which looks very much what nicol proposed.
>
> Airlift into C++17? Even just for vector/string?
> Ducks runs for cover.
>

Sure looks handy. It'd also be nice if you could write into the reserved
area of string and vector and then to a resize without initialization /
with default initialization (only useful for POD types).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/36f776bf-3cd7-4755-8d11-6ea02dad4636%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Op woensdag 11 januari 2017 11:16:10 UTC+1 schreef=
 gmis...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Tuesday, January 10, 2017 at 1:59:22 PM UTC+13, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" 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">On segunda-feira, 9 de janeiro de 2017 13:42:1=
3 PST <a rel=3D"nofollow">gmis...@gmail.com</a> wrote:
<br>&gt; If these basic API&#39;s squeezed in C++17 it might make some peop=
le who aren&#39;t
<br>&gt; happy more happy!
<br>
<br>Extremely unlikely. The draft has been approved, so I don&#39;t think a=
nyone will=20
<br>allow new features to be added. Defect correction and removing things t=
hat are=20
<br>potentially dangerous could happen; adding overloads or other omissions=
 by=20
<br>mistake could happen, if they can be considered part of an existing fea=
ture=20
<br>being added.
<br>
<br>New features, forget it.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I assume you saw Ion=C2=A0posted this:=
</div><div><br></div><div><a href=3D"http://www.boost.org/doc/libs/1_63_0/d=
oc/html/container/extended_functionality.html#container.extended_functional=
ity.default_initialialization" rel=3D"nofollow" target=3D"_blank" onmousedo=
wn=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boos=
t.org%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%2Fextended_functionali=
ty.html%23container.extended_functionality.default_initialialization\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVfcmIUif46BN-vAbIZTBDrvHyFg&#39;;return =
true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%2Fextended=
_functionality.html%23container.extended_functionality.default_initialializ=
ation\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVfcmIUif46BN-vAbIZTBDrvHyFg&=
#39;;return true;">http://www.boost.org/doc/libs/<wbr>1_63_0/doc/html/conta=
iner/<wbr>extended_functionality.html#<wbr>container.extended_<wbr>function=
ality.default_<wbr>initialialization</a> </div><div><br></div><div>Which lo=
oks very much what nicol proposed.<br><br></div><div>Airlift=C2=A0into C++1=
7? Even just for vector/string?</div><div>Ducks runs for cover.</div></div>=
</blockquote><div><br></div><div>Sure looks handy. It&#39;d also be nice if=
 you could write into the reserved area of string and vector and then to a =
resize without initialization / with default initialization (only useful fo=
r POD types).=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/36f776bf-3cd7-4755-8d11-6ea02dad4636%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36f776bf-3cd7-4755-8d11-6ea02dad4636=
%40isocpp.org</a>.<br />

------=_Part_1206_1979630076.1484560563939--

------=_Part_1205_727252079.1484560563939--

.