Topic: Controversy and debate: Uninitialized variables
Author: Jonathan Coe <jbcoe@me.com>
Date: Tue, 17 Jun 2014 17:53:33 +0200
Raw View
--089e011615fc6348cb04fc0a25ff
Content-Type: text/plain; charset=UTF-8
Sometimes (in embedded systems for instance) initialization cost is
considered to be significant. C++ generally follows the philosophy that you
only pay for what you need. User- or library-defined types can force
primitives to be initialized or value initialize them.
for instance:
http://www.boost.org/doc/libs/1_55_0/libs/utility/value_init.htm
Regards,
Jon
On 17 June 2014 17:49, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> This is going to be controversial, but lets get into it.
>
> The fact that `int x;` creates an uninitialized integer instead of a
> default initialized one is completely wrong. I consider it a major defect
> in the language, a bug in the standard.
>
> One of my favorite C++11 API's is the atomic API. The reason is that it
> does the right thing when it comes to correctness vs speed. By default, the
> path of least resistance is to have everything sequentially consistent
> which is the safest but also slowest memory ordering. If you know what
> you're doing and need some speed, you can opt to use less safe orderings.
> Even better, every use of the less safe ordering is tagged right there in
> the source code (without a comment)! It really doesn't get much better than
> that in terms of API design. It follows Scott Meyers maxim of "Making
> interfaces easy to use correctly and hard to use incorrectly" perfectly.
>
> Initialization in C++ is the exact opposite of this. The easiest thing to
> do is write bugs by forgetting to initialize things. How many of you have
> spent long debugging sessions only to track the source to an uninitialized
> variable? Not only that, but initialization in C++ is a horrible mess. lets
> look at the list:
>
> Default initialization
> Value Initialization
> Copy Initialization
> Direct Initialization
> Aggregate Initialization
> List initialization
> Reference Initialization
> Constant Initialization
>
> Do you know by memory how all of those work and their gotchas? I sure as
> hell don't and I pity the novice developer who tries. Do we need this level
> of complexity?
>
> Here is a sketch one possible way we could solve this problem:
>
> int x; //<-default initialized to 0
> int x = void; //<-uninitialized, I know what I'm doing
> volatile int x; //<-uninitialized, because we can't introduce
> additional writes to volatile variables or break existing device driver
> code.
>
> Like the atomic API, the default action is the safe action, with options
> to remove the restraints should you need it.
> What I'm suggesting is that everything be initialized by default. And yes
> that means all legacy code that flips the switch to use the next version of
> the C++ language. If someone has a compelling performance argument for
> leaving something uninitialized, the = void syntax is there for them.
>
> What are the advantages:
> 1) Safe by default, if someone does a statistical survey, I'm confident
> that after this change the average amount of time spent debugging C++ code
> will go down.
> 2) Dangerous places are marked (=void) as such, bringing attention and
> carefully scrutiny by the person reading code.
> 3) Less boilerplate code. Particularly with constructors I don't have to
> write a bunch of stupid initialization code for my ints, floats, and
> pointers.
> 4) Initialization behavior matches static and global variables. One less
> "except when" for Herb Sutter to write about in GotW.
>
> Counter arguments:
> 1) This will slow down everyone's programs!
>
> No it won't. Compilers have been doing something called constant
> propagation for over 20 years.
>
> That is, this code:
>
> int x = 0;
> x = 1;
>
> Will be optimized to this:
> int x = 1;
>
> 2) This will break C compatibility!
>
> No it won't. extern "C" code will still have the old behavior. There is no
> C breakage here. The data being passed to and from C code is still the
> same, regardless of whether or not it was initialized by the compiler.
>
> 3) Why do we need this? Compilers, static checkers, and debugging tools
> can detect uninitialized use!
>
> Not always, and these tools are not always available. For example valgrind
> is unusable on large resource consuming code bases. Also, even if there is
> a tool why am I wasting my time checking this crap? I'd rather not be able
> to easily write these bugs in the first place. Fix this and one *major*
> class of bugs in C++ go away forever.
>
> 4) It will break legacy code!
>
> In some cases yes, but lets take a deeper look at the possibilities here:
>
> There are legacy code bases with real uninitialized variable bugs in them
> today. Your company probably has 1 or 2 in their large code base and
> miraculously its still working fine. If all of the sudden these things get
> fixed, it may change the behavior of your program, causing a "bug" in the
> sense that production is now operating differently. What used to be
> undefined behavior just got defined. I don't see this as a huge problem. If
> you have bugs in your code they need to be fixed. Also I do not believe
> this is a good enough reason to continue the subpar status quo forever.
>
> Then there may be other cases, for example some kind of strange embedded
> code or device drivers. Perhaps you instantiate an object over top of a
> hardware memory address. If you are doing this, you are probably also
> marking your variables as volatile, and that as I proposed above is still
> uninitialized so you won't be affected.
>
> Maybe you're doing something really funky like putting your call stack on
> some special memory, and default initialization will cause additional
> writes which will cause your program to fail. If you're doing this kind of
> crazy low level stuff, then you should know enough to be able to fix your
> code. Also you will be now annotating these instances with = void or
> volatile and that has the additional benefit of saying in your code,
> without a comment "*hey I'm doing some funny stuff here with
> initialization*".
>
> 5) I'm so good I don't write these kinds of bugs
>
> Congratulations, good job. Your colleagues however do write these kind of
> bugs and will continue to do so until the end of time. Sometimes you may
> even get to debug for them.
>
> I really enjoy C++, for all of its warts. I believe unlike other languages
> which come and go, C++ has staying power and will be around and growing for
> a long time. C++ is the fastest and most versatile language on the planet.
> I don't see everyone jumping ship anytime soon for a complete rewrite
> language like D (sorry Andrei). We're stuck with C++, so lets make it a
> better language.
>
> Doing something like this would be huge. It would require a lot of
> analysis to get right. My simple idea of =void (inspired from D, thanks
> Andrei) may not work in all cases and will need to be fleshed out further.
>
> Please now, convince if you can why this is a bad idea. Why should we
> continue to inflict wasted hours of debugging sessions for these kinds of
> silly easy to write bugs on the future of C++? Can you think of any
> possible reason uninitialized by default is good other than "maintaining
> legacy code".
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e011615fc6348cb04fc0a25ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sometimes (in embedded systems for instance) initializatio=
n cost is considered to be significant. C++ generally follows the philosoph=
y that you only pay for what you need. User- or library-defined types can f=
orce primitives to be initialized or value initialize them.<div>
<br></div><div>for instance:=C2=A0<a href=3D"http://www.boost.org/doc/libs/=
1_55_0/libs/utility/value_init.htm">http://www.boost.org/doc/libs/1_55_0/li=
bs/utility/value_init.htm</a></div><div><br></div><div>Regards,</div><div><=
br>
</div><div>Jon</div></div><div class=3D"gmail_extra"><br><br><div class=3D"=
gmail_quote">On 17 June 2014 17:49, Matthew Fioravante <span dir=3D"ltr">&l=
t;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@=
gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is going to be controv=
ersial, but lets get into it.<br><br>The fact that `int x;` creates an unin=
itialized integer instead of a default initialized one is completely wrong.=
I consider it a major defect in the language, a bug in the standard.<br>
<br>One of my favorite C++11 API's is the atomic API. The reason is tha=
t it does the right thing when it comes to correctness vs speed. By default=
, the path of least resistance is to have everything sequentially consisten=
t which is the safest but also slowest memory ordering. If you know what yo=
u're doing and need some speed, you can opt to use less safe orderings.=
Even better, every use of the less safe ordering is tagged right there in =
the source code (without a comment)! It really doesn't get much better =
than that in terms of API design. It follows Scott Meyers maxim of "Ma=
king interfaces easy to use correctly and hard to use incorrectly" per=
fectly.<br>
<br>Initialization in C++ is the exact opposite of this. The easiest thing =
to do is write bugs by forgetting to initialize things. How many of you hav=
e spent long debugging sessions only to track the source to an uninitialize=
d variable? Not only that, but initialization in C++ is a horrible mess. le=
ts look at the list:<br>
<br>Default initialization<br>Value Initialization<br>Copy Initialization<b=
r>Direct Initialization<br>Aggregate Initialization<br>List initialization<=
br>Reference Initialization<br>Constant Initialization<br><br>Do you know b=
y memory how all of those work and their gotchas? I sure as hell don't =
and I pity the novice developer who tries. Do we need this level of complex=
ity?<br>
<br>Here is a sketch one possible way we could solve this problem:<br><br>=
=C2=A0=C2=A0=C2=A0 int x; //<-default initialized to 0<br>=C2=A0=C2=A0=
=C2=A0 int x =3D void; //<-uninitialized, I know what I'm doing<br>=
=C2=A0=C2=A0=C2=A0 volatile int x; //<-uninitialized, because we can'=
;t introduce additional writes to volatile variables or break existing devi=
ce driver code.<br>
<br>Like the atomic API, the default action is the safe action, with option=
s to remove the restraints should you need it.<br>What I'm suggesting i=
s that everything be initialized by default. And yes that means all legacy =
code that flips the switch to use the next version of the C++ language. If =
someone has a compelling performance argument for leaving something uniniti=
alized, the =3D void syntax is there for them.<br>
<br>What are the advantages:<br>1) Safe by default, if someone does a stati=
stical survey, I'm confident that after this change the average amount =
of time spent debugging C++ code will go down.<br>2) Dangerous places are m=
arked (=3Dvoid) as such, bringing attention and carefully scrutiny by the p=
erson reading code.<br>
3) Less boilerplate code. Particularly with constructors I don't have t=
o write a bunch of stupid initialization code for my ints, floats, and poin=
ters.<br>4) Initialization behavior matches static and global variables. On=
e less "except when" for Herb Sutter to write about in GotW.<br>
<br>Counter arguments:<br>1) This will slow down everyone's programs!<b=
r><br>No it won't. Compilers have been doing something called constant =
propagation for over 20 years.<br><br>That is, this code:<br><br>=C2=A0=C2=
=A0=C2=A0 int x =3D 0;<br>
=C2=A0=C2=A0=C2=A0 x =3D 1;<br><br>Will be optimized to this:<br>=C2=A0=C2=
=A0=C2=A0 int x =3D 1;<br><br>2) This will break C compatibility!<br><br>No=
it won't. extern "C" code will still have the old behavior. =
There is no C breakage here. The data being passed to and from C code is st=
ill the same, regardless of whether or not it was initialized by the compil=
er.<br>
<br>3) Why do we need this? Compilers, static checkers, and debugging tools=
can detect uninitialized use!<br><br>Not always, and these tools are not a=
lways available. For example valgrind is unusable on large resource consumi=
ng code bases. Also, even if there is a tool why am I wasting my time check=
ing this crap? I'd rather not be able to easily write these bugs in the=
first place. Fix this and one <b>major</b> class of bugs in C++ go away fo=
rever.<br>
<br>4) It will break legacy code!<br><br>In some cases yes, but lets take a=
deeper look at the possibilities here:<br><br>There are legacy code bases =
with real uninitialized variable bugs in them today. Your company probably =
has 1 or 2 in their large code base and miraculously its still working fine=
.. If all of the sudden these things get fixed, it may change the behavior o=
f your program, causing a "bug" in the sense that production is n=
ow operating differently. What used to be undefined behavior just got defin=
ed. I don't see this as a huge problem. If you have bugs in your code t=
hey need to be fixed. Also I do not believe this is a good enough reason to=
continue the subpar status quo forever.<br>
<br>Then there may be other cases, for example some kind of strange embedde=
d code or device drivers. Perhaps you instantiate an object over top of a h=
ardware memory address. If you are doing this, you are probably also markin=
g your variables as volatile, and that as I proposed above is still uniniti=
alized so you won't be affected.<br>
<br>Maybe you're doing something really funky like putting your call st=
ack on some special memory, and default initialization will cause additiona=
l writes which will cause your program to fail.=C2=A0 If you're doing t=
his kind of crazy low level stuff, then you should know enough to be able t=
o fix your code. Also you will be now annotating these instances with =3D v=
oid or volatile and that has the additional benefit of saying in your code,=
without a comment "<i>hey I'm doing some funny stuff here with in=
itialization</i>".<br>
<br>5) I'm so good I don't write these kinds of bugs<br><br>Congrat=
ulations, good job. Your colleagues however do write these kind of bugs and=
will continue to do so until the end of time. Sometimes you may even get t=
o debug for them.<br>
<br>I really enjoy C++, for all of its warts. I believe unlike other langua=
ges which come and go, C++ has staying power and will be around and growing=
for a long time. C++ is the fastest and most versatile language on the pla=
net.=C2=A0 I don't see everyone jumping ship anytime soon for a complet=
e rewrite language like D (sorry Andrei). We're stuck with C++, so lets=
make it a better language.<br>
<br>Doing something like this would be huge. It would require a lot of anal=
ysis to get right. My simple idea of =3Dvoid (inspired from D, thanks Andre=
i) may not work in all cases and will need to be fleshed out further.<br>
<br>Please now, convince if you can why this is a bad idea. Why should we c=
ontinue to inflict wasted hours of debugging sessions for these kinds of si=
lly easy to write bugs on the future of C++? Can you think of any possible =
reason uninitialized by default is good other than "maintaining legacy=
code".<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br><br><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#8888=
88">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011615fc6348cb04fc0a25ff--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 17 Jun 2014 18:58:10 +0300
Raw View
On 17 June 2014 18:49, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> This is going to be controversial, but lets get into it.
>
> The fact that `int x;` creates an uninitialized integer instead of a default
> initialized one is completely wrong. I consider it a major defect in the
> language, a bug in the standard.
Well, it's not a bug by any definition that the committee uses, since we know
about it, and it's 100% intentional.
> Please now, convince if you can why this is a bad idea. Why should we
char buf[MEGABYTE];
buf[HERE] = something;
buf[THERE] = something_else;
According to what you propose, the mere definition of buf would go
through all of that
megabyte and zero-initialize the chars.
Or perhaps you meant that arrays are an exception? What about
struct X { char buf[MEGABYTE]; };
X x;
Is this also an exception to the rule?
How many performance expectations of how much existing code do you think this
change would break?
The committee's answer to this question has always been "too many, too
much", and
I don't see that changing.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 17 Jun 2014 17:58:12 +0200
Raw View
--001a1135f0fc66d58d04fc0a3830
Content-Type: text/plain; charset=UTF-8
On 17 June 2014 17:49, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> Please now, convince if you can why this is a bad idea.
>
Because IMO the correct answer is that the default should be for requiring
users to explicitly initialize the variable, and have a way to mark it the
few times they want an uninitialized variable. All initializing to zero
does is move the problem from something that static analyzers can catch to
something they can't.
Plus, that ship has sailed with C a long, long time ago...
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1135f0fc66d58d04fc0a3830
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 17 June 2014 17:49, Matthew =
Fioravante <span dir=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmail.com" =
target=3D"_blank">fmatthew5876@gmail.com</a>></span> wrote:<br><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Please now, convince if you=
can why this is a bad idea.</div></blockquote><div><br></div><div>Because =
IMO the correct answer is that the default should be for requiring users to=
explicitly initialize the variable, and have a way to mark it the few time=
s they want an uninitialized variable. =C2=A0All initializing to zero does =
is move the problem from something that static analyzers can catch to somet=
hing they can't.</div>
<div><br></div><div>Plus, that ship has sailed with C a long, long time ago=
....</div><div>--=C2=A0</div></div>=C2=A0Nevin ":-)" Liber=C2=A0 &=
lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin=
@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135f0fc66d58d04fc0a3830--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:00:47 -0700 (PDT)
Raw View
------=_Part_273_10551587.1403020847511
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 11:53:35 AM UTC-4, Jonathan Coe wrote:
>
> Sometimes (in embedded systems for instance) initialization cost is
> considered to be significant. C++ generally follows the philosophy that you
> only pay for what you need. User- or library-defined types can force
> primitives to be initialized or value initialize them.
>
The key word here is "sometimes". Sometimes initialization is expensive,
most of the time it is not or just optimized away. For those some times,
you can use =void, or boost value_init (we could have a std::noinit<T>
wrapper), or some other specialized method. As long as this method exists,
the only pay for what you need philosophy still sticks. If you find
initialization to be expensive, use the alternative method (which also
documents your intent in the code without comments).
Most of the time when people talk about initialization costs, they are
doing something like constructing a vector of objects. This initialization
cost is already in the standard because vector will initialize the objects.
Nothing I am proposing here changes that or makes it worse.
> for instance:
> http://www.boost.org/doc/libs/1_55_0/libs/utility/value_init.htm
>
> Regards,
>
> Jon
>
>
> On 17 June 2014 17:49, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>> This is going to be controversial, but lets get into it.
>>
>> The fact that `int x;` creates an uninitialized integer instead of a
>> default initialized one is completely wrong. I consider it a major defect
>> in the language, a bug in the standard.
>>
>> One of my favorite C++11 API's is the atomic API. The reason is that it
>> does the right thing when it comes to correctness vs speed. By default, the
>> path of least resistance is to have everything sequentially consistent
>> which is the safest but also slowest memory ordering. If you know what
>> you're doing and need some speed, you can opt to use less safe orderings.
>> Even better, every use of the less safe ordering is tagged right there in
>> the source code (without a comment)! It really doesn't get much better than
>> that in terms of API design. It follows Scott Meyers maxim of "Making
>> interfaces easy to use correctly and hard to use incorrectly" perfectly.
>>
>> Initialization in C++ is the exact opposite of this. The easiest thing to
>> do is write bugs by forgetting to initialize things. How many of you have
>> spent long debugging sessions only to track the source to an uninitialized
>> variable? Not only that, but initialization in C++ is a horrible mess. lets
>> look at the list:
>>
>> Default initialization
>> Value Initialization
>> Copy Initialization
>> Direct Initialization
>> Aggregate Initialization
>> List initialization
>> Reference Initialization
>> Constant Initialization
>>
>> Do you know by memory how all of those work and their gotchas? I sure as
>> hell don't and I pity the novice developer who tries. Do we need this level
>> of complexity?
>>
>> Here is a sketch one possible way we could solve this problem:
>>
>> int x; //<-default initialized to 0
>> int x = void; //<-uninitialized, I know what I'm doing
>> volatile int x; //<-uninitialized, because we can't introduce
>> additional writes to volatile variables or break existing device driver
>> code.
>>
>> Like the atomic API, the default action is the safe action, with options
>> to remove the restraints should you need it.
>> What I'm suggesting is that everything be initialized by default. And yes
>> that means all legacy code that flips the switch to use the next version of
>> the C++ language. If someone has a compelling performance argument for
>> leaving something uninitialized, the = void syntax is there for them.
>>
>> What are the advantages:
>> 1) Safe by default, if someone does a statistical survey, I'm confident
>> that after this change the average amount of time spent debugging C++ code
>> will go down.
>> 2) Dangerous places are marked (=void) as such, bringing attention and
>> carefully scrutiny by the person reading code.
>> 3) Less boilerplate code. Particularly with constructors I don't have to
>> write a bunch of stupid initialization code for my ints, floats, and
>> pointers.
>> 4) Initialization behavior matches static and global variables. One less
>> "except when" for Herb Sutter to write about in GotW.
>>
>> Counter arguments:
>> 1) This will slow down everyone's programs!
>>
>> No it won't. Compilers have been doing something called constant
>> propagation for over 20 years.
>>
>> That is, this code:
>>
>> int x = 0;
>> x = 1;
>>
>> Will be optimized to this:
>> int x = 1;
>>
>> 2) This will break C compatibility!
>>
>> No it won't. extern "C" code will still have the old behavior. There is
>> no C breakage here. The data being passed to and from C code is still the
>> same, regardless of whether or not it was initialized by the compiler.
>>
>> 3) Why do we need this? Compilers, static checkers, and debugging tools
>> can detect uninitialized use!
>>
>> Not always, and these tools are not always available. For example
>> valgrind is unusable on large resource consuming code bases. Also, even if
>> there is a tool why am I wasting my time checking this crap? I'd rather not
>> be able to easily write these bugs in the first place. Fix this and one
>> *major* class of bugs in C++ go away forever.
>>
>> 4) It will break legacy code!
>>
>> In some cases yes, but lets take a deeper look at the possibilities here:
>>
>> There are legacy code bases with real uninitialized variable bugs in them
>> today. Your company probably has 1 or 2 in their large code base and
>> miraculously its still working fine. If all of the sudden these things get
>> fixed, it may change the behavior of your program, causing a "bug" in the
>> sense that production is now operating differently. What used to be
>> undefined behavior just got defined. I don't see this as a huge problem. If
>> you have bugs in your code they need to be fixed. Also I do not believe
>> this is a good enough reason to continue the subpar status quo forever.
>>
>> Then there may be other cases, for example some kind of strange embedded
>> code or device drivers. Perhaps you instantiate an object over top of a
>> hardware memory address. If you are doing this, you are probably also
>> marking your variables as volatile, and that as I proposed above is still
>> uninitialized so you won't be affected.
>>
>> Maybe you're doing something really funky like putting your call stack on
>> some special memory, and default initialization will cause additional
>> writes which will cause your program to fail. If you're doing this kind of
>> crazy low level stuff, then you should know enough to be able to fix your
>> code. Also you will be now annotating these instances with = void or
>> volatile and that has the additional benefit of saying in your code,
>> without a comment "*hey I'm doing some funny stuff here with
>> initialization*".
>>
>> 5) I'm so good I don't write these kinds of bugs
>>
>> Congratulations, good job. Your colleagues however do write these kind of
>> bugs and will continue to do so until the end of time. Sometimes you may
>> even get to debug for them.
>>
>> I really enjoy C++, for all of its warts. I believe unlike other
>> languages which come and go, C++ has staying power and will be around and
>> growing for a long time. C++ is the fastest and most versatile language on
>> the planet. I don't see everyone jumping ship anytime soon for a complete
>> rewrite language like D (sorry Andrei). We're stuck with C++, so lets make
>> it a better language.
>>
>> Doing something like this would be huge. It would require a lot of
>> analysis to get right. My simple idea of =void (inspired from D, thanks
>> Andrei) may not work in all cases and will need to be fleshed out further.
>>
>> Please now, convince if you can why this is a bad idea. Why should we
>> continue to inflict wasted hours of debugging sessions for these kinds of
>> silly easy to write bugs on the future of C++? Can you think of any
>> possible reason uninitialized by default is good other than "maintaining
>> legacy code".
>>
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_273_10551587.1403020847511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 11:53:35 AM UTC-4, Jonat=
han Coe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Sometimes (in embedded systems for instance) initialization cost is consid=
ered to be significant. C++ generally follows the philosophy that you only =
pay for what you need. User- or library-defined types can force primitives =
to be initialized or value initialize them.</div></blockquote><div><br>The =
key word here is "sometimes". Sometimes initialization is expensive, most o=
f the time it is not or just optimized away. For those some times, you can =
use =3Dvoid, or boost value_init (we could have a std::noinit<T> wrap=
per), or some other specialized method. As long as this method exists, the =
only pay for what you need philosophy still sticks. If you find initializat=
ion to be expensive, use the alternative method (which also documents your =
intent in the code without comments).<br><br>Most of the time when people t=
alk about initialization costs, they are doing something like constructing =
a vector of objects. This initialization cost is already in the standard be=
cause vector will initialize the objects. Nothing I am proposing here chang=
es that or makes it worse.<br><br><br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>
<br></div><div>for instance: <a href=3D"http://www.boost.org/doc/libs/=
1_55_0/libs/utility/value_init.htm" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flib=
s%2F1_55_0%2Flibs%2Futility%2Fvalue_init.htm\46sa\75D\46sntz\0751\46usg\75A=
FQjCNFbZSv9YeySMEmUkIQTdCvIym_K3Q';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_=
0%2Flibs%2Futility%2Fvalue_init.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNFbZS=
v9YeySMEmUkIQTdCvIym_K3Q';return true;">http://www.boost.<wbr>org/doc/libs/=
1_55_0/libs/<wbr>utility/value_init.htm</a></div><div><br></div><div>Regard=
s,</div><div><br>
</div><div>Jon</div></div><div><br><br><div class=3D"gmail_quote">On 17 Jun=
e 2014 17:49, Matthew Fioravante <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"C7m3y5gFNcQJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">fmatth...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is going to be controv=
ersial, but lets get into it.<br><br>The fact that `int x;` creates an unin=
itialized integer instead of a default initialized one is completely wrong.=
I consider it a major defect in the language, a bug in the standard.<br>
<br>One of my favorite C++11 API's is the atomic API. The reason is that it=
does the right thing when it comes to correctness vs speed. By default, th=
e path of least resistance is to have everything sequentially consistent wh=
ich is the safest but also slowest memory ordering. If you know what you're=
doing and need some speed, you can opt to use less safe orderings. Even be=
tter, every use of the less safe ordering is tagged right there in the sour=
ce code (without a comment)! It really doesn't get much better than that in=
terms of API design. It follows Scott Meyers maxim of "Making interfaces e=
asy to use correctly and hard to use incorrectly" perfectly.<br>
<br>Initialization in C++ is the exact opposite of this. The easiest thing =
to do is write bugs by forgetting to initialize things. How many of you hav=
e spent long debugging sessions only to track the source to an uninitialize=
d variable? Not only that, but initialization in C++ is a horrible mess. le=
ts look at the list:<br>
<br>Default initialization<br>Value Initialization<br>Copy Initialization<b=
r>Direct Initialization<br>Aggregate Initialization<br>List initialization<=
br>Reference Initialization<br>Constant Initialization<br><br>Do you know b=
y memory how all of those work and their gotchas? I sure as hell don't and =
I pity the novice developer who tries. Do we need this level of complexity?=
<br>
<br>Here is a sketch one possible way we could solve this problem:<br><br>&=
nbsp; int x; //<-default initialized to 0<br> &nb=
sp; int x =3D void; //<-uninitialized, I know what I'm doing<br> &n=
bsp; volatile int x; //<-uninitialized, because we can't introduce=
additional writes to volatile variables or break existing device driver co=
de.<br>
<br>Like the atomic API, the default action is the safe action, with option=
s to remove the restraints should you need it.<br>What I'm suggesting is th=
at everything be initialized by default. And yes that means all legacy code=
that flips the switch to use the next version of the C++ language. If some=
one has a compelling performance argument for leaving something uninitializ=
ed, the =3D void syntax is there for them.<br>
<br>What are the advantages:<br>1) Safe by default, if someone does a stati=
stical survey, I'm confident that after this change the average amount of t=
ime spent debugging C++ code will go down.<br>2) Dangerous places are marke=
d (=3Dvoid) as such, bringing attention and carefully scrutiny by the perso=
n reading code.<br>
3) Less boilerplate code. Particularly with constructors I don't have to wr=
ite a bunch of stupid initialization code for my ints, floats, and pointers=
..<br>4) Initialization behavior matches static and global variables. One le=
ss "except when" for Herb Sutter to write about in GotW.<br>
<br>Counter arguments:<br>1) This will slow down everyone's programs!<br><b=
r>No it won't. Compilers have been doing something called constant propagat=
ion for over 20 years.<br><br>That is, this code:<br><br> =
int x =3D 0;<br>
x =3D 1;<br><br>Will be optimized to this:<br> &nbs=
p; int x =3D 1;<br><br>2) This will break C compatibility!<br><br>No =
it won't. extern "C" code will still have the old behavior. There is no C b=
reakage here. The data being passed to and from C code is still the same, r=
egardless of whether or not it was initialized by the compiler.<br>
<br>3) Why do we need this? Compilers, static checkers, and debugging tools=
can detect uninitialized use!<br><br>Not always, and these tools are not a=
lways available. For example valgrind is unusable on large resource consumi=
ng code bases. Also, even if there is a tool why am I wasting my time check=
ing this crap? I'd rather not be able to easily write these bugs in the fir=
st place. Fix this and one <b>major</b> class of bugs in C++ go away foreve=
r.<br>
<br>4) It will break legacy code!<br><br>In some cases yes, but lets take a=
deeper look at the possibilities here:<br><br>There are legacy code bases =
with real uninitialized variable bugs in them today. Your company probably =
has 1 or 2 in their large code base and miraculously its still working fine=
.. If all of the sudden these things get fixed, it may change the behavior o=
f your program, causing a "bug" in the sense that production is now operati=
ng differently. What used to be undefined behavior just got defined. I don'=
t see this as a huge problem. If you have bugs in your code they need to be=
fixed. Also I do not believe this is a good enough reason to continue the =
subpar status quo forever.<br>
<br>Then there may be other cases, for example some kind of strange embedde=
d code or device drivers. Perhaps you instantiate an object over top of a h=
ardware memory address. If you are doing this, you are probably also markin=
g your variables as volatile, and that as I proposed above is still uniniti=
alized so you won't be affected.<br>
<br>Maybe you're doing something really funky like putting your call stack =
on some special memory, and default initialization will cause additional wr=
ites which will cause your program to fail. If you're doing this kind=
of crazy low level stuff, then you should know enough to be able to fix yo=
ur code. Also you will be now annotating these instances with =3D void or v=
olatile and that has the additional benefit of saying in your code, without=
a comment "<i>hey I'm doing some funny stuff here with initialization</i>"=
..<br>
<br>5) I'm so good I don't write these kinds of bugs<br><br>Congratulations=
, good job. Your colleagues however do write these kind of bugs and will co=
ntinue to do so until the end of time. Sometimes you may even get to debug =
for them.<br>
<br>I really enjoy C++, for all of its warts. I believe unlike other langua=
ges which come and go, C++ has staying power and will be around and growing=
for a long time. C++ is the fastest and most versatile language on the pla=
net. I don't see everyone jumping ship anytime soon for a complete re=
write language like D (sorry Andrei). We're stuck with C++, so lets make it=
a better language.<br>
<br>Doing something like this would be huge. It would require a lot of anal=
ysis to get right. My simple idea of =3Dvoid (inspired from D, thanks Andre=
i) may not work in all cases and will need to be fleshed out further.<br>
<br>Please now, convince if you can why this is a bad idea. Why should we c=
ontinue to inflict wasted hours of debugging sessions for these kinds of si=
lly easy to write bugs on the future of C++? Can you think of any possible =
reason uninitialized by default is good other than "maintaining legacy code=
".<span><font color=3D"#888888"><br>
<br><br><br></font></span></div><span><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
C7m3y5gFNcQJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"C7m3y5gFNcQJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_273_10551587.1403020847511--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 17 Jun 2014 18:02:05 +0200
Raw View
--047d7ba97a884a59f804fc0a4644
Content-Type: text/plain; charset=UTF-8
On 17 June 2014 18:00, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>
> ost of the time when people talk about initialization costs, they are
> doing something like constructing a vector of objects. This initialization
> cost is already in the standard because vector will initialize the objects.
> Nothing I am proposing here changes that or makes it worse.
>
Where can we see your benchmarking code and results?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7ba97a884a59f804fc0a4644
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 17 June 2014 18:00, Matthew Fioravante <span dir=3D"ltr=
"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5=
876@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><br>ost of =
the time when people talk about initialization costs, they are doing someth=
ing like constructing a vector of objects. This initialization cost is alre=
ady in the standard because vector will initialize the objects. Nothing I a=
m proposing here changes that or makes it worse.</div>
</div></blockquote><div><br></div><div>Where can we see your benchmarking c=
ode and results?=C2=A0</div></div>-- <br>=C2=A0Nevin ":-)" Liber=
=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7ba97a884a59f804fc0a4644--
.
Author: Stack Machine <stackmachine@hotmail.com>
Date: Tue, 17 Jun 2014 09:05:16 -0700 (PDT)
Raw View
------=_Part_211_3110880.1403021116359
Content-Type: text/plain; charset=UTF-8
I think that both sides have some compelling arguments. How about this:
int i; // compiletime error: no initializer
int i = 0; // initialize to 0
int i = void; // ok, explicitly uninitialized
Yes, this does break backwards compatibility, but in a way that produces a
compiletime error. Conversion tools shouldn't be too hard to write either.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_211_3110880.1403021116359
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that both sides have some compelling arguments. Ho=
w about this:<br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// compiletime error: no ini=
tializer</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// initialize to 0</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// ok, explicitly uninitialized</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div>Yes, this does break backwards compatibility, but in a way that =
produces a compiletime error. Conversion tools shouldn't be too hard to wri=
te either.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_211_3110880.1403021116359--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:07:30 -0700 (PDT)
Raw View
------=_Part_285_17506883.1403021250950
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 11:58:11 AM UTC-4, Ville Voutilainen wrote:
>
> On 17 June 2014 18:49, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
> > This is going to be controversial, but lets get into it.
> >
> > The fact that `int x;` creates an uninitialized integer instead of a
> default
> > initialized one is completely wrong. I consider it a major defect in the
> > language, a bug in the standard.
>
> Well, it's not a bug by any definition that the committee uses, since we
> know
> about it, and it's 100% intentional.
>
> > Please now, convince if you can why this is a bad idea. Why should we
>
>
> char buf[MEGABYTE];
>
Arrays are not an exception.
If buf[MEGABYTE] is a global, its already initialized to 0.
If its a class member or on the stack, you can say
char buf[MEGABYTE] = void;
to skip initialization. Otherwise it gets filled with 0s.
> buf[HERE] = something;
> buf[THERE] = something_else;
>
> According to what you propose, the mere definition of buf would go
> through all of that
> megabyte and zero-initialize the chars.
>
> Or perhaps you meant that arrays are an exception? What about
>
> struct X { char buf[MEGABYTE]; };
>
> X x;
>
> Is this also an exception to the rule?
>
Possibilities here:
struct X { char buf[MEGABYTE] = void }; //All default constructed objects
of type X will have uninitialized buffers
X x; //< buf is not initialized
//OR
struct X { char buf[MEGABYTE]; };
X x = void; //<-This particular x will not initialize its members by
default (Same as X x; now)
>
> How many performance expectations of how much existing code do you think
> this
> change would break?
>
We would need to study this to find out.
>
> The committee's answer to this question has always been "too many, too
> much", and
> I don't see that changing.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_285_17506883.1403021250950
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 11:58:11 AM UTC-4, Ville=
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 June =
2014 18:49, Matthew Fioravante <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"ecsSg8VB8ZkJ" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">fma=
tth...@gmail.com</a>> wrote:
<br>> This is going to be controversial, but lets get into it.
<br>>
<br>> The fact that `int x;` creates an uninitialized integer instead of=
a default
<br>> initialized one is completely wrong. I consider it a major defect =
in the
<br>> language, a bug in the standard.
<br>
<br>Well, it's not a bug by any definition that the committee uses, since w=
e know
<br>about it, and it's 100% intentional.
<br>
<br>> Please now, convince if you can why this is a bad idea. Why should=
we
<br>
<br>
<br>char buf[MEGABYTE];
<br></blockquote><div><br>Arrays are not an exception.<br><br>If buf[MEGABY=
TE] is a global, its already initialized to 0.<br><br>If its a class member=
or on the stack, you can say<br><br>char buf[MEGABYTE] =3D void; <br><br>t=
o skip initialization. Otherwise it gets filled with 0s.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>buf[HERE] =3D something;
<br>buf[THERE] =3D something_else;
<br>
<br>According to what you propose, the mere definition of buf would go
<br>through all of that
<br>megabyte and zero-initialize the chars.
<br>
<br>Or perhaps you meant that arrays are an exception? What about
<br>
<br>struct X { char buf[MEGABYTE]; };
<br>
<br>X x;
<br>
<br>Is this also an exception to the rule?
<br></blockquote><div><br>Possibilities here:<br><br>struct X { char buf[ME=
GABYTE] =3D void }; //All default constructed objects of type X will have u=
ninitialized buffers<br>X x; //< buf is not initialized<br><br>//OR<br>s=
truct X { char buf[MEGABYTE]; };<br>X x =3D void; //<-This particular x =
will not initialize its members by default (Same as X x; now)<br> <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>How many performance expectations of how much existing code do you thin=
k this
<br>change would break?
<br></blockquote><div><br>We would need to study this to find out. <br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
<br>The committee's answer to this question has always been "too many, too
<br>much", and
<br>I don't see that changing.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_285_17506883.1403021250950--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 17 Jun 2014 19:09:17 +0300
Raw View
On 17 June 2014 19:07, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>> char buf[MEGABYTE];
> Arrays are not an exception.
> If buf[MEGABYTE] is a global, its already initialized to 0.
> If its a class member or on the stack, you can say
> char buf[MEGABYTE] = void;
> to skip initialization. Otherwise it gets filled with 0s.
Yeah. And this sort of a difference to existing code has killed this idea
EVERY TIME.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:09:36 -0700 (PDT)
Raw View
------=_Part_284_16630540.1403021376733
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 12:02:48 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 17 June 2014 18:00, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>>
>> ost of the time when people talk about initialization costs, they are
>> doing something like constructing a vector of objects. This initialization
>> cost is already in the standard because vector will initialize the objects.
>> Nothing I am proposing here changes that or makes it worse.
>>
>
> Where can we see your benchmarking code and results?
>
Not sure what you're asking for. Before this idea, std::vector<T> will
always initialize its T contents. After this idea it will still do the same
thing. Not sure how a benchmark is needed for that.
--
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)
> 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_284_16630540.1403021376733
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 12:02:48 PM UTC-4, Nevin=
":-)" Liber wrote:<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">On 17 June 2014 18:00, Matthew Fioravante <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"AIhABfZc1N0J"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">fmatth...@gmail.com</a>></span> wrote:<b=
r><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>ost of the time wh=
en people talk about initialization costs, they are doing something like co=
nstructing a vector of objects. This initialization cost is already in the =
standard because vector will initialize the objects. Nothing I am proposing=
here changes that or makes it worse.</div>
</div></blockquote><div><br></div><div>Where can we see your benchmarking c=
ode and results? </div></div></div></div></blockquote><div><br>Not sur=
e what you're asking for. Before this idea, std::vector<T> will alway=
s initialize its T contents. After this idea it will still do the same thin=
g. Not sure how a benchmark is needed for that.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>-- <br> Nevin ":-=
)" Liber <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"AIhABfZc1N0J" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@evilov=
erlord.com</a><wbr>> (847) 691-1404
</div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_284_16630540.1403021376733--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 17 Jun 2014 18:12:51 +0200
Raw View
--001a1134c904c0d85e04fc0a6c30
Content-Type: text/plain; charset=UTF-8
On 17 June 2014 18:09, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> After this idea it will still do the same thing. Not sure how a benchmark
> is needed for that.
>
You've made a bold, unsubstantiated claim this has no performance
implications, and hand wave away anyone who disagrees. This is a question
that data quite easily answer, and anyone making performance claims ought
to have it.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1134c904c0d85e04fc0a6c30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 17 June 2014 18:09, Matthew Fioravante <span dir=3D"ltr=
"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5=
876@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">=C2=A0After this idea it wi=
ll still do the same thing. Not sure how a benchmark is needed for that.</d=
iv></blockquote>
<div><br></div><div>You've made a bold, unsubstantiated claim this has =
no performance implications, and hand wave away anyone who disagrees. =C2=
=A0This is a question that data quite easily answer, and anyone making perf=
ormance claims ought to have it.</div>
</div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134c904c0d85e04fc0a6c30--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Tue, 17 Jun 2014 09:20:13 -0700 (PDT)
Raw View
------=_Part_188_12382666.1403022013776
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" Liber wrote:
>
> On 17 June 2014 17:49, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>> Please now, convince if you can why this is a bad idea.
>>
>
> Because IMO the correct answer is that the default should be for requiring
> users to explicitly initialize the variable, and have a way to mark it the
> few times they want an uninitialized variable. All initializing to zero
> does is move the problem from something that static analyzers can catch to
> something they can't.
>
I agree. I strongly believe that is there is a default behavior for
variable declarations with no initializer, it shouldn't initialize the
variable at all. However, I'm not convinced that there *needs* to be a
default case except for maintaining compatibility.
> Plus, that ship has sailed with C a long, long time ago...
>
I think it would be reasonable to add the option
explicit-non-initialization to the standard, e.g.
int foo; // doesn't initialize
int foo = __no_init__; // doesn't initialize
int foo = 0; // initializes
(I'm avoiding picking a real syntax for this for now.) This lets people be
explicit rather than implicit when they don't want to initialize a variable
at declaration, which would then allow compilers to emit a warning (not an
error!) if you don't do this. However, I'd hope that compiler authors would
only emit the warning when their static analyzer couldn't prove that you
always set the variable anyway. That is, the following shouldn't warn:
int func() {
int foo;
if(something)
foo = 1;
else
foo = 2;
}
- Jim
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_188_12382666.1403022013776
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" L=
iber 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"><d=
iv>On 17 June 2014 17:49, Matthew Fioravante <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"gOXO1LATzEYJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">fmatth...@gmail.com</a>></span> wrote:<br=
><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Please now, convince if you=
can why this is a bad idea.</div></blockquote><div><br></div><div>Because =
IMO the correct answer is that the default should be for requiring users to=
explicitly initialize the variable, and have a way to mark it the few time=
s they want an uninitialized variable. All initializing to zero does =
is move the problem from something that static analyzers can catch to somet=
hing they can't.</div></div></div></div></blockquote><div><br>I agree. I st=
rongly believe that is there is a default behavior for variable declaration=
s with no initializer, it shouldn't initialize the variable at all. However=
, I'm not convinced that there *needs* to be a default case except for main=
taining compatibility.<br> </div><blockquote class=3D"gmail_quote" sty=
le=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>Plus, that ship has sailed with C a long, long time ago...<=
/div></div></div></div></blockquote><div><br>I think it would be reasonable=
to add the option explicit-non-initialization to the standard, e.g.<br><br=
> int foo; // doesn't initialize<br> int foo =3D __no_init__; /=
/ doesn't initialize<br> int foo =3D 0; // initializes<br><br>(I'm av=
oiding picking a real syntax for this for now.) This lets people be explici=
t rather than implicit when they don't want to initialize a variable at dec=
laration, which would then allow compilers to emit a warning (not an error!=
) if you don't do this. However, I'd hope that compiler authors would only =
emit the warning when their static analyzer couldn't prove that you always =
set the variable anyway. That is, the following shouldn't warn:<br><br>&nbs=
p; int func() {<br> int foo;<br> if(som=
ething)<br> foo =3D 1;<br> =
else<br> foo =3D 2;<br> }<br><br>- Jim<=
br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_188_12382666.1403022013776--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 17 Jun 2014 09:22:19 -0700
Raw View
Em ter 17 jun 2014, =E0s 08:49:57, Matthew Fioravante escreveu:
> Counter arguments:
> 1) This will slow down everyone's programs!
>=20
> No it won't. Compilers have been doing something called constant=20
> propagation for over 20 years.
>=20
> That is, this code:
>=20
> int x =3D 0;
> x =3D 1;
>=20
> Will be optimized to this:
> int x =3D 1;
Except when the compiler can't prove that it is the same and so the constan=
t=20
propagation fails.
int x;
switch (otherVar) {
case 1:
x =3D 1;
break;
case 2:
case 256:
case 32767:
x =3D 2;
break;
};
The compiler doesn't know whether the four values in the switch and the onl=
y=20
possible values.
Now, if you write that code above and use x afterwards, modern compilers wi=
ll=20
probably produce a warning that x might be uninitialised, so people will en=
d=20
up either adding a default case or initialising x. However, that's a QoI is=
sue=20
and the developer might just disable the warning because they know better.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:24:29 -0700 (PDT)
Raw View
------=_Part_419_15585578.1403022269665
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 12:09:18 PM UTC-4, Ville Voutilainen wrote:
>
> On 17 June 2014 19:07, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
> >> char buf[MEGABYTE];
> > Arrays are not an exception.
> > If buf[MEGABYTE] is a global, its already initialized to 0.
> > If its a class member or on the stack, you can say
> > char buf[MEGABYTE] = void;
> > to skip initialization. Otherwise it gets filled with 0s.
>
> Yeah. And this sort of a difference to existing code has killed this idea
> EVERY TIME.
>
Why not write a conversion tool to check for instances of this?
On Tuesday, June 17, 2014 12:13:33 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 17 June 2014 18:09, Matthew Fioravante <fmatth...@gmail.com> wrote:
>
>> After this idea it will still do the same thing. Not sure how a
>> benchmark is needed for that.
>>
>
> You've made a bold, unsubstantiated claim this has no performance
> implications, and hand wave away anyone who disagrees. This is a question
> that data quite easily answer, and anyone making performance claims ought
> to have it.
>
The 2 things we are discussing (initializing aggregates by default vs
standard library container initialization behavior) are orthogonal. Do you
test the performance of std::map every time you write a file parsing
routine?
Ville's point about buf[MEGABYTE] is valid. There are real performance
implications there because the behavior changes with arrays.
Standard library containers do not behave any differently, they always
initialize their contents by default as they were designed to do in the
beginning.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_419_15585578.1403022269665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 12:09:18 PM UTC-4, Ville=
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 June =
2014 19:07, Matthew Fioravante <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"dS3XOtO8nM0J" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">fma=
tth...@gmail.com</a>> wrote:
<br>>> char buf[MEGABYTE];
<br>> Arrays are not an exception.
<br>> If buf[MEGABYTE] is a global, its already initialized to 0.
<br>> If its a class member or on the stack, you can say
<br>> char buf[MEGABYTE] =3D void;
<br>> to skip initialization. Otherwise it gets filled with 0s.
<br>
<br>Yeah. And this sort of a difference to existing code has killed this id=
ea
<br>EVERY TIME.
<br></blockquote><div><br>Why not write a conversion tool to check for inst=
ances of this?<br><br>On Tuesday, June 17, 2014 12:13:33 PM UTC-4, Nevin ":=
-)" Liber 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"lt=
r">On 17 June 2014 18:09, Matthew Fioravante <span dir=3D"ltr"><<a targe=
t=3D"_blank">fmatth...@gmail.com</a>></span> wrote:<br><div><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"> After this idea it wi=
ll still do the same thing. Not sure how a benchmark is needed for that.</d=
iv></blockquote>
<div><br></div><div>You've made a bold, unsubstantiated claim this has=20
no performance implications, and hand wave away anyone who disagrees.=20
This is a question that data quite easily answer, and anyone making=
=20
performance claims ought to have it.</div></div></div></div></blockquote><d=
iv><br>The 2 things we are discussing (initializing aggregates by default v=
s standard library container initialization behavior) are orthogonal. Do yo=
u test the performance of std::map every time you write a file parsing rout=
ine? <br><br>Ville's point about buf[MEGABYTE] is valid. There are real per=
formance implications there because the behavior changes with arrays.<br><b=
r>Standard library containers do not behave any differently, they always in=
itialize their contents by default as they were designed to do in the begin=
ning.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">
</div>-- <br> Nevin ":-)" Liber <mailto:<a target=3D"_blank">=
ne...@eviloverlord.com</a><wbr>> (847) 691-1404
</div></div>
</blockquote><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_419_15585578.1403022269665--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:27:35 -0700 (PDT)
Raw View
------=_Part_158_22036477.1403022455200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, June 17, 2014 12:22:24 PM UTC-4, Thiago Macieira wrote:
>
> Em ter 17 jun 2014, =C3=A0s 08:49:57, Matthew Fioravante escreveu:=20
> > Counter arguments:=20
> > 1) This will slow down everyone's programs!=20
> >=20
> > No it won't. Compilers have been doing something called constant=20
> > propagation for over 20 years.=20
> >=20
> > That is, this code:=20
> >=20
> > int x =3D 0;=20
> > x =3D 1;=20
> >=20
> > Will be optimized to this:=20
> > int x =3D 1;=20
>
> Except when the compiler can't prove that it is the same and so the=20
> constant=20
> propagation fails.=20
>
> int x;=20
> switch (otherVar) {=20
> case 1:=20
> x =3D 1;=20
> break;=20
> case 2:=20
> case 256:=20
> case 32767:=20
> x =3D 2;=20
> break;=20
> };=20
>
> The compiler doesn't know whether the four values in the switch and the=
=20
> only=20
> possible values.=20
>
> Now, if you write that code above and use x afterwards, modern compilers=
=20
> will=20
> probably produce a warning that x might be uninitialised, so people will=
=20
> end=20
> up either adding a default case or initialising x. However, that's a QoI=
=20
> issue=20
> and the developer might just disable the warning because they know better=
..=20
>
If you believe this to impact performance, and want to be unsafe (in the=20
case that someone adds and passes in a new enum value tomorrow to your=20
library), you can say int x =3D void here.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_158_22036477.1403022455200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 12:22:24 PM UTC-4, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em ter 17 jun=
2014, =C3=A0s 08:49:57, Matthew Fioravante escreveu:
<br>> Counter arguments:
<br>> 1) This will slow down everyone's programs!
<br>>=20
<br>> No it won't. Compilers have been doing something called constant=
=20
<br>> propagation for over 20 years.
<br>>=20
<br>> That is, this code:
<br>>=20
<br>> int x =3D 0;
<br>> x =3D 1;
<br>>=20
<br>> Will be optimized to this:
<br>> int x =3D 1;
<br>
<br>Except when the compiler can't prove that it is the same and so the con=
stant=20
<br>propagation fails.
<br>
<br> int x;
<br> switch (otherVar) {
<br> case 1:
<br>  =
; x =3D 1;
<br>  =
; break;
<br> case 2:
<br> case 256:
<br> case 32767:
<br>  =
; x =3D 2;
<br>  =
; break;
<br> };
<br>
<br>The compiler doesn't know whether the four values in the switch and the=
only=20
<br>possible values.
<br>
<br>Now, if you write that code above and use x afterwards, modern compiler=
s will=20
<br>probably produce a warning that x might be uninitialised, so people wil=
l end=20
<br>up either adding a default case or initialising x. However, that's a Qo=
I issue=20
<br>and the developer might just disable the warning because they know bett=
er.
<br></blockquote><div><br>If you believe this to impact performance, and wa=
nt to be unsafe (in the case that someone adds and passes in a new enum val=
ue tomorrow to your library), you can say int x =3D void here. <br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_158_22036477.1403022455200--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 17 Jun 2014 18:29:22 +0200
Raw View
--047d7b3a8176d60ea304fc0aa7cb
Content-Type: text/plain; charset=UTF-8
On 17 June 2014 18:24, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>
> Standard library containers do not behave any differently, they always
> initialize their contents by default as they were designed to do in the
> beginning.
>
No, they don't. They use the construct function in the allocator. One use
of allocators is to eliminate the cost of zero initializing large vectors.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b3a8176d60ea304fc0aa7cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 17 June 2014 18:24, Matthew Fioravante <span dir=3D"ltr=
"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5=
876@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Standard library contai=
ners do not behave any differently, they always initialize their contents b=
y default as they were designed to do in the beginning.<br>
</div></blockquote><div><br></div><div>No, they don't. =C2=A0They use t=
he construct function in the allocator. =C2=A0One use of allocators is to e=
liminate the cost of zero initializing large vectors.</div></div>-- <br>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847)=
691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b3a8176d60ea304fc0aa7cb--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 17 Jun 2014 09:34:52 -0700 (PDT)
Raw View
------=_Part_2495_2077330.1403022892369
Content-Type: text/plain; charset=UTF-8
Any change in behavior/performance for a standard library container would
be a QoI problem. I'm not proposing any changes to the standard library
with regards to how it does or does not initialize things.
On Tuesday, June 17, 2014 12:30:04 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 17 June 2014 18:24, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>>
>> Standard library containers do not behave any differently, they always
>> initialize their contents by default as they were designed to do in the
>> beginning.
>>
>
> No, they don't. They use the construct function in the allocator. One
> use of allocators is to eliminate the cost of zero initializing large
> vectors.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)
> 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2495_2077330.1403022892369
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Any change in behavior/performance for a standard library =
container would be a QoI problem. I'm not proposing any changes to the stan=
dard library with regards to how it does or does not initialize things.<br>=
<br><br>On Tuesday, June 17, 2014 12:30:04 PM UTC-4, Nevin ":-)" Liber wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 17 June =
2014 18:24, Matthew Fioravante <span dir=3D"ltr"><<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"KIJPVwGfqYkJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">fmatth...@gmail.com</a>></span> wrote:<br><div><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Standard library contai=
ners do not behave any differently, they always initialize their contents b=
y default as they were designed to do in the beginning.<br>
</div></blockquote><div><br></div><div>No, they don't. They use the c=
onstruct function in the allocator. One use of allocators is to elimi=
nate the cost of zero initializing large vectors.</div></div>-- <br> N=
evin ":-)" Liber <mailto:<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"KIJPVwGfqYkJ" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ne..=
..@eviloverlord.com</a><wbr>> (847) 691-1404
</div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2495_2077330.1403022892369--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 17 Jun 2014 09:59:29 -0700
Raw View
Em ter 17 jun 2014, =E0s 09:27:35, Matthew Fioravante escreveu:
> If you believe this to impact performance, and want to be unsafe (in the=
=20
> case that someone adds and passes in a new enum value tomorrow to your=20
> library), you can say int x =3D void here.=20
If we were designing a new language with no existing codebase, I'd definite=
ly=20
agree with you.
Changing C++ some 40 years after the fact (if we can include the C legacy) =
is=20
a no-go.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 17 Jun 2014 19:39:36 +0200
Raw View
--001a11c2e9cca2b53804fc0ba07a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante escreveu:
> > If you believe this to impact performance, and want to be unsafe (in th=
e
> > case that someone adds and passes in a new enum value tomorrow to your
> > library), you can say int x =3D void here.
>
> If we were designing a new language with no existing codebase, I'd
> definitely
> agree with you.
>
> Changing C++ some 40 years after the fact (if we can include the C legacy=
)
> is
> a no-go.
>
>
Actually, I think such a change (force the user to specify initialization
or not) could be made if
there was a big amount of uncontroversial data on issues that the current
rules make easy to get into.
Also, if there is a way to easily point these issues once the change is in
place, then why not?
Basically, I don't think the initial proposal is a good idea, but
disallowing implicit uninitialization at all, and having an explicit way to
specify uninitialization, would be good enough
for the compiler to point issues immediately, and would help code readers
too to understand the intent.
It appear to me to be more compatible with C++11 and previous C++ versions
to do it that way.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2e9cca2b53804fc0ba07a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <span dir=3D"ltr">=
<<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieir=
a.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante e=
screveu:<br>
<div class=3D"">> If you believe this to impact performance, and want to=
be unsafe (in the<br>
> case that someone adds and passes in a new enum value tomorrow to your=
<br>
> library), you can say int x =3D void here.<br>
<br>
</div>If we were designing a new language with no existing codebase, I'=
d definitely<br>
agree with you.<br>
<br>
Changing C++ some 40 years after the fact (if we can include the C legacy) =
is<br>
a no-go.<br>
<div class=3D""><div class=3D"h5"><br></div></div></blockquote><div><br></d=
iv><div>Actually, I think such a change (force the user to specify initiali=
zation or not) could be made if</div><div>there was a=C2=A0big amount of un=
controversial data on issues that the current rules make easy to get into.<=
/div>
<div>Also, if there is a way to easily point these issues once the change i=
s in place, then why not?</div><div><br></div><div>Basically, I don't t=
hink the initial proposal is a good idea, but disallowing implicit uninitia=
lization at all, and having an explicit way to specify=C2=A0uninitializatio=
n, would be good enough</div>
<div>for the compiler to point issues immediately, and would help code read=
ers too to understand the intent.=C2=A0</div><div>It appear to me to be mor=
e compatible with C++11 and previous C++ versions to do it that way.</div><=
div>
<br></div><div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2e9cca2b53804fc0ba07a--
.
Author: gmisocpp@gmail.com
Date: Tue, 17 Jun 2014 17:01:35 -0700 (PDT)
Raw View
------=_Part_374_14567490.1403049695410
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, June 18, 2014 5:39:38 AM UTC+12, Klaim - Jo=C3=ABl Lamotte wr=
ote:
>
>
>
>
> On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante escreveu:
>> > If you believe this to impact performance, and want to be unsafe (in t=
he
>> > case that someone adds and passes in a new enum value tomorrow to your
>> > library), you can say int x =3D void here.
>>
>> If we were designing a new language with no existing codebase, I'd=20
>> definitely
>> agree with you.
>>
>> Changing C++ some 40 years after the fact (if we can include the C=20
>> legacy) is
>> a no-go.
>>
>>
> Actually, I think such a change (force the user to specify initialization=
=20
> or not) could be made if
> there was a big amount of uncontroversial data on issues that the current=
=20
> rules make easy to get into.
> Also, if there is a way to easily point these issues once the change is i=
n=20
> place, then why not?
>
> Basically, I don't think the initial proposal is a good idea, but=20
> disallowing implicit uninitialization at all, and having an explicit way =
to=20
> specify uninitialization, would be good enough
> for the compiler to point issues immediately, and would help code readers=
=20
> too to understand the intent.=20
> It appear to me to be more compatible with C++11 and previous C++ version=
s=20
> to do it that way.
>
>
>
I agree and think having the ability to not initialize something is=20
definitely a useful thing and needs it's own thread / study group. There's=
=20
lots of opportunity here for performance and clarity gains, I think.
For instance.
class Person { ... };
uninitialized Person p; // Not interesting.
template<T> class Optional { // Could simplify Optional?
uninitialized T m_obj; // More interesting.
};
uninitliazed iostream stdin, stdout, stderr; // Complex initialization of=
=20
global done later.
uninitialized int x; // I'm not sure what I want yet, it's depending on the=
=20
path take, don't warn me though.
Other types of uninitialization, I'd really like to see.
std::string s;
s.uninitialized_resize(N);
c_apI(&s[0]);
s.exact_uninitialized_resize(N); // Don't double size or anything. I just=
=20
want to store this string. / it'll never grow.
c_api(&s);
Other out there ideas:
char* p =3D new uninitialized Person[100];
<ironic>Guy proposes default initialization. Get's offers of even less=20
initialization. Only in C++... </ironic>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_374_14567490.1403049695410
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, June 18, 2014 5:39:38 AM UTC+12, Kla=
im - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 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">=
<br><div><br><br><div class=3D"gmail_quote">On Tue, Jun 17, 2014 at 6:59 PM=
, Thiago Macieira <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;" h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"q-v-vgmHqDEJ=
">thi...@macieira.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew =
Fioravante escreveu:<br>
<div>> If you believe this to impact performance, and want to be unsafe =
(in the<br>
> case that someone adds and passes in a new enum value tomorrow to your=
<br>
> library), you can say int x =3D void here.<br>
<br>
</div>If we were designing a new language with no existing codebase, I'd de=
finitely<br>
agree with you.<br>
<br>
Changing C++ some 40 years after the fact (if we can include the C legacy) =
is<br>
a no-go.<br>
<div><div><br></div></div></blockquote><div><br></div><div>Actually, I thin=
k such a change (force the user to specify initialization or not) could be =
made if</div><div>there was a big amount of uncontroversial data on is=
sues that the current rules make easy to get into.</div>
<div>Also, if there is a way to easily point these issues once the change i=
s in place, then why not?</div><div><br></div><div>Basically, I don't think=
the initial proposal is a good idea, but disallowing implicit uninitializa=
tion at all, and having an explicit way to specify uninitialization, w=
ould be good enough</div>
<div>for the compiler to point issues immediately, and would help code read=
ers too to understand the intent. </div><div>It appear to me to be mor=
e compatible with C++11 and previous C++ versions to do it that way.</div><=
div>
<br></div><div><br></div></div></div></div></blockquote><div><br></div><div=
>I agree and think having the ability to not initialize something is d=
efinitely a useful thing and needs it's own thread / study group. There's l=
ots of opportunity here for performance and clarity gains, I think.</div><d=
iv><br></div><div>For instance.</div><div><br></div><div>class Person { ...=
};</div><div>uninitialized Person p; // Not interesting.</div><div><=
br></div><div>template<T> class Optional { // Could simplify Optional=
?</div><div> uninitialized T m_obj; // More interesting.</div><=
div>};</div><div><br></div><div>uninitliazed iostream stdin, stdout, stderr=
; // Complex initialization of global done later.</div><div><br></div><div>=
uninitialized int x; // I'm not sure what I want yet, it's depending on the=
path take, don't warn me though.</div><div><br></div><div>Other type=
s of uninitialization, I'd really like to see.</div><div>std::string s;</di=
v><div>s.uninitialized_resize(N);</div><div>c_apI(&s[0]);</div><div><br=
></div><div>s.exact_uninitialized_resize(N); // Don't double size or anythi=
ng. I just want to store this string. / it'll never grow.</div><div>c_api(&=
amp;s);</div><div><br></div><div><br></div><div>Other out there ideas:</div=
><div><br></div><div>char* p =3D new uninitialized Person[100];</=
div><div><br></div><div><ironic>Guy proposes default initialization. =
Get's offers of even less initialization. Only in C++... </ironic></d=
iv></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_374_14567490.1403049695410--
.
Author: Michael McLaughlin <mikebmcl@gmail.com>
Date: Tue, 17 Jun 2014 20:33:12 -0400
Raw View
--20cf301b67b3c82be704fc1167a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think there's a way forward here that could improve things without
changing the status quo.
Consider the following hypothetical pseudo-proposal:
- Add a syntax to explicitly specify that a variable should not be
initialized (e.g. "int x =3D void; float z[100000] =3D void;" - why " =3D
void"? void is already reserved and can't legally be used like that now so
it seems like a good candidate).
- Add some language to clearly specify that the
existing C/C++03/C++11/C++14 behavior (i.e. "int x; float z[100000];" means
uninitialized) is the default behavior. Then state that a conforming
implementation can give users the option to explicitly opt-in to a
different behavior. The intent being that compiler switches (or defining
some macro or whatever the implementer wants to do) can change that, but
that the user doesn't need to do anything different to keep the existing
uninitialized behavior.
I believe that those changes would be enough to give compiler vendors the
leeway needed to do several things via switches (or macro definitions,
etc.). First, they could add a behavior where the absence of the explicit
uninitialized syntax and no compiler-provable initialization produces a
compilation error. Second, they could do the same thing except instead of
an error diagnostic it emits a warning and produces zero/nullptr
initialization. Third, they could do the same thing as the second option
except with no diagnostic.
Q. Why do we need these changes? Can't implementers do this now?
A. Not with standard C++. Without a legal syntax for explicitly specifying
that a variable should not be initialized, users have no standard way to
let the compiler know that a variable is intentionally uninitialized. The
fallback then is an implementation-defined attribute or some non-standard
behavior (e.g. a language extension).
Q. What's wrong with implementation-defined attributes?
A. Nothing for features that aren't ripe for standardization. But since
this involves vendor-neutral behavior, then unless every implementer uses
the same attribute in exactly the same way, the code will start to get ugly
and unreadable pretty quickly with all of the #ifdefs (not to mention that
there's no guarantee that they'd all use attributes and no guarantee that
things would remain stable from version to version so you'd probably have
#ifdefs even if they did just happen to use the same syntax). From my
perspective as a developer, working through an old codebase and adding in "
=3D void" where appropriate is time consuming but easy enough. Adding a hug=
e
block of conditional macros to every intentionally uninitialized variable
and maintaining them over the years as new and different compilers are used
to compile that code promises to be a nightmare.
Q. So what about using a standardized attribute?
A. I think the " =3D void" syntax is nicer, but if using an attribute (or
something else that can be standardized) instead is what it would take
to get a consensus then I'm not opposed to it. Another benefit to using " =
=3D
void" is that maybe the ISO C folks would be willing to consider that as an
addition to C (for substantially the same reasons as given here). I don't
know what they'd make of a proposal that required attributes. [ Note: If
both the ISO C and ISO C++ committees agreed to add explicit uninitialized
variables and they both adopted the same syntax, then arguments against
this due to C-compatibility issues go away. Then it's just a matter of
legacy code and the maintainers of that code would have to opt-in to this
behavior such that even that shouldn't be a problem. They can either adopt
it at their own pace (and maybe eliminate some unknown bugs along the way)
or stick with classic syntax and ignore this feature. -- end note ]
Q. But you aren't actually proposing a standardized way to eliminate
unintentionally uninitialized variables are you?
A. You caught me; my proposal doesn't do that. It proposes a syntax for
explicit uninitialized variables along with some language that gives
implementers the leeway they need to create better tools that are still
standards-conformant. I like the three hypothetical behaviors I described
earlier (compilation error; warning + zero initialization; and zero
initialization without a diagnostic) and hope that implementers
would provide all three. Indeed a formal proposal might even include
language in a Note section that strongly encouraged implementers to
provide users a way to get each of those three behaviors. But proposing
standardizing compiler switches (or any of the other ways I can think of to
actually produce any of those behaviors while leaving the default behavior
alone)? What I propose above involves a change to the language (whether
it's " =3D void" or a newly standardized attribute or whatever). That
change might break C compatibility in some way that can't be coded around
(though I'm not sure that it would since it's opt-in syntax that lets
implementers enable opt-in behavior). Even without the possible break with
C, it's poking a hornet's nest. I leave it to someone braver than me to
propose standardizing compiler switches.
Q. If it doesn't propose eliminating unintentionally uninitialized
variables, why bother with it at all?
A. Regardless of whether implementers make use of it to help eliminate
unintentionally uninitialized variables, I think there is merit to letting
programmers denote that a variable is intentionally uninitialized. To me
the statement "int x =3D void;" expresses a programmer's intent in a way th=
at
"int x;" does not. As well, when code consistently uses "int x =3D
void;" then seeing "double y;" is a pretty clear sign that the code
involving 'y' bears closer scrutiny.
In summary, eliminating the default uninitialized behavior seems to
be impractical for the foreseeable future. This alternative gives us a
chance to let programmers express their intent more clearly. It also gives
implementers (by virtue of the opt-in clause) the ability to provide
standards-conformant tools that will help programmers find and eliminate
uninitialized variable bugs, while still respecting the programmer's wishes
to not have, e.g., an array of fifty thousand floats be automatically
zero-initialized. Further, if this became part of C++, it's possible that
the Committee could eventually consider deprecating the current
initialization behavior with an aim towards eventually removing it in favor
of requiring that programmers use the " =3D void" syntax when they actually
desire an uninitialized variable. Not that they will or even should.
But this proposal would make that something which could eventually be
practical. In the meantime it would give programmers an elegant,
concise way to make their code more expressive.
;;;
If it wouldn't be a clear waste of everyone's time, I'm willing to turn
that into a formal proposal that can be considered seriously. I wish I had
been able to make it to Rapperswil so I could float it around a bit there
to get a sense of whether it has any chance. If anyone sees any serious
flaws in it please do let me know. If you think the idea has merit, please
feel free to let me know that as well (whether on-list or off-).
Thanks!
-Mike
On Tue, Jun 17, 2014 at 1:39 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:
>
>
>
> On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante escreveu:
>> > If you believe this to impact performance, and want to be unsafe (in t=
he
>> > case that someone adds and passes in a new enum value tomorrow to your
>> > library), you can say int x =3D void here.
>>
>> If we were designing a new language with no existing codebase, I'd
>> definitely
>> agree with you.
>>
>> Changing C++ some 40 years after the fact (if we can include the C
>> legacy) is
>> a no-go.
>>
>>
> Actually, I think such a change (force the user to specify initialization
> or not) could be made if
> there was a big amount of uncontroversial data on issues that the current
> rules make easy to get into.
> Also, if there is a way to easily point these issues once the change is i=
n
> place, then why not?
>
> Basically, I don't think the initial proposal is a good idea, but
> disallowing implicit uninitialization at all, and having an explicit way =
to
> specify uninitialization, would be good enough
> for the compiler to point issues immediately, and would help code readers
> too to understand the intent.
> It appear to me to be more compatible with C++11 and previous C++ version=
s
> to do it that way.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--20cf301b67b3c82be704fc1167a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I think there's=C2=A0a way forward here that coul=
d=C2=A0improve things without changing the status quo.</div><div>=C2=A0</di=
v><div>Consider the following hypothetical pseudo-proposal:</div><div><br><=
/div><div>-=C2=A0Add a syntax to explicitly specify that a variable should =
not be initialized (e.g. "int x =3D void; float z[100000] =3D void;&qu=
ot;=C2=A0- why " =3D void"?=C2=A0void is=C2=A0already reserved an=
d can't legally be used like that now so it seems like a good candidate=
).</div>
<div>-=C2=A0Add some language=C2=A0to clearly=C2=A0specify that=C2=A0the ex=
isting=C2=A0C/C++03/C++11/C++14=C2=A0behavior (i.e. "int x; float z[10=
0000];" means uninitialized)=C2=A0is the default behavior.=C2=A0Then s=
tate=C2=A0that a conforming implementation can give users the option to exp=
licitly opt-in to a different behavior. The intent being that compiler swit=
ches (or defining some macro=C2=A0or whatever the implementer wants to do) =
can change that, but that the user doesn't need to do anything differen=
t to keep the existing uninitialized behavior.</div>
<div><br></div><div>I believe that those changes would be enough to give co=
mpiler vendors the leeway needed to do several things via switches (or macr=
o definitions, etc.). First, they could add a behavior where the absence of=
the explicit uninitialized syntax and no compiler-provable initialization =
produces a compilation error. Second, they could do the same thing except i=
nstead of an error diagnostic it emits a warning and produces=C2=A0zero/nul=
lptr initialization. Third, they could do the same thing as the second opti=
on except with no diagnostic.</div>
<div>=C2=A0</div><div>Q. Why do we need these changes? Can't=C2=A0imple=
menters do this now?</div><div>=C2=A0</div><div>A. Not with standard C++. W=
ithout a legal syntax for explicitly specifying that a variable should not =
be initialized, users have no standard=C2=A0way to let the compiler know th=
at a variable is intentionally uninitialized. The fallback then is an imple=
mentation-defined attribute or some=C2=A0non-standard behavior (e.g. a=C2=
=A0language extension).</div>
<div>=C2=A0</div><div>=C2=A0</div><div>Q. What's wrong with implementat=
ion-defined attributes?</div><div>=C2=A0</div><div>A. Nothing for features =
that aren't ripe for standardization. But since this involves vendor-ne=
utral behavior, then unless every implementer uses the same attribute in ex=
actly the same way, the code will start to get ugly and unreadable pretty q=
uickly with all of the #ifdefs (not to mention that there's no guarante=
e that they'd all use attributes and no guarantee that things would=C2=
=A0remain stable=C2=A0from version to version so you'd probably have #i=
fdefs even if they did just happen to use the same syntax). From my perspec=
tive as a developer,=C2=A0working through an old=C2=A0codebase and adding i=
n " =3D void" where appropriate is time consuming but easy enough=
.. Adding=C2=A0a huge block of conditional macros to every=C2=A0intentionall=
y uninitialized=C2=A0variable and maintaining them over the years as new an=
d different compilers are used to compile that code=C2=A0promises to be a n=
ightmare.</div>
<div>=C2=A0</div><div>=C2=A0</div><div>Q. So what about using a standardize=
d attribute?</div><div>=C2=A0</div><div>A. I think the " =3D void"=
; syntax is nicer, but if using an attribute (or something else that can be=
standardized)=C2=A0instead=C2=A0is what it=C2=A0would take to=C2=A0get a c=
onsensus then I'm not opposed to it. Another benefit to using " =
=3D void" is that=C2=A0maybe the ISO C folks=C2=A0would be willing to =
consider that as an addition to C (for substantially the same reasons as gi=
ven here). I don't know what they'd make of a proposal that require=
d attributes. [ Note: If both the ISO C and ISO C++ committees agreed to ad=
d explicit uninitialized variables and they both=C2=A0adopted the same synt=
ax, then arguments against this due to C-compatibility=C2=A0issues go away.=
Then=C2=A0it's just a matter of legacy code and the maintainers of tha=
t code would have to opt-in to this behavior such that even that shouldn=
9;t be a problem. They can either adopt it at their own pace (and maybe eli=
minate some unknown bugs along the way) or stick with classic syntax and ig=
nore this feature. -- end note ]</div>
<div>=C2=A0</div><div>=C2=A0</div><div>Q. But you aren't actually propo=
sing a standardized way to eliminate unintentionally uninitialized variable=
s are you?</div><div>=C2=A0</div><div>A. You caught me; my proposal doesn&#=
39;t do that. It proposes a=C2=A0syntax for explicit uninitialized variable=
s along with some language that gives implementers the leeway they need to =
create better tools that are still standards-conformant. I like the three h=
ypothetical behaviors I described earlier (compilation error; warning + zer=
o initialization; and zero initialization without a diagnostic) and hope th=
at implementers would=C2=A0provide all three. Indeed a formal proposal migh=
t even=C2=A0include language in a Note section=C2=A0that strongly encourage=
d=C2=A0implementers to provide=C2=A0users a way to=C2=A0get each of those t=
hree behaviors.=C2=A0But proposing standardizing compiler switches (or any =
of the other ways I can think of to actually produce any of those behaviors=
while leaving the default behavior alone)? What I=C2=A0propose above invol=
ves a change to the language (whether it's " =3D void" or a n=
ewly=C2=A0standardized attribute or whatever).=C2=A0That change=C2=A0might =
break C compatibility in some way that can't be coded around (though I&=
#39;m not sure that it would since it's opt-in syntax that lets impleme=
nters enable opt-in behavior). Even without the possible break with C,=C2=
=A0it's poking a hornet's nest. I leave it to someone braver than m=
e=C2=A0to propose standardizing compiler switches.</div>
<div>=C2=A0</div><div>=C2=A0</div><div>Q. If it doesn't propose elimina=
ting unintentionally uninitialized variables, why bother with it at all?</d=
iv><div>=C2=A0</div><div>A.=C2=A0Regardless of whether=C2=A0implementers ma=
ke use of it=C2=A0to help=C2=A0eliminate unintentionally uninitialized vari=
ables,=C2=A0I think there is merit to letting programmers denote that a var=
iable is intentionally uninitialized. To me the statement "int x =3D v=
oid;"=C2=A0expresses=C2=A0a programmer's=C2=A0intent in a way that=
"int x;" does not. As well, when code consistently uses "in=
t x =3D void;"=C2=A0then=C2=A0seeing=C2=A0"double y;" is a p=
retty clear sign that the code involving 'y' bears closer scrutiny.=
</div>
<div>=C2=A0</div><div>In summary, eliminating the default uninitialized beh=
avior=C2=A0seems to be=C2=A0impractical for the foreseeable future. This al=
ternative=C2=A0gives us a chance to let programmers express their intent mo=
re clearly.=C2=A0It also gives implementers (by virtue of the opt-in clause=
) the ability to provide standards-conformant tools that will help programm=
ers find and eliminate uninitialized variable bugs, while still respecting =
the programmer's wishes to not have, e.g.,=C2=A0an array of fifty thous=
and floats be automatically zero-initialized. Further, if=C2=A0this became =
part of C++, it's possible that the Committee=C2=A0could=C2=A0eventuall=
y consider deprecating the current initialization behavior with an aim towa=
rds eventually removing it in favor of requiring that programmers use the &=
quot; =3D void" syntax when they actually desire an uninitialized vari=
able. Not that they will or even should. But=C2=A0this proposal=C2=A0would =
make that something which could eventually be practical. In the meantime it=
would give programmers an elegant, concise=C2=A0way to make their code mor=
e expressive.</div>
<div>=C2=A0</div><div>;;;</div><div>=C2=A0</div><div>If it wouldn't be =
a clear waste of everyone's time, I'm willing to turn that into a f=
ormal proposal that can be considered seriously. I wish I had been able to =
make it to Rapperswil so I could float it around a bit there to get a sense=
of whether it has any chance. If anyone sees any serious flaws in it pleas=
e do let me know. If you think the idea has merit, please feel free to let =
me know that as well (whether on-list or off-).</div>
<div>=C2=A0</div><div>Thanks!</div><div>=C2=A0</div><div>-Mike</div><div>=
=C2=A0</div><div><br></div><div class=3D"gmail_extra"><br clear=3D"all"><di=
v><br></div><div class=3D"gmail_quote">On Tue, Jun 17, 2014 at 1:39 PM, Kla=
im - Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmai=
l.com" target=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<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-l=
eft-style:solid"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">
<div>On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <span dir=3D"ltr"><=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>></span> wrote:<br>
<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-l=
eft-style:solid">Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante e=
screveu:<br>
<div>> If you believe this to impact performance, and want to be unsafe =
(in the<br>
> case that someone adds and passes in a new enum value tomorrow to your=
<br>
> library), you can say int x =3D void here.<br>
<br>
</div>If we were designing a new language with no existing codebase, I'=
d definitely<br>
agree with you.<br>
<br>
Changing C++ some 40 years after the fact (if we can include the C legacy) =
is<br>
a no-go.<br>
<div><div><br></div></div></blockquote><div><br></div></div><div>Actually, =
I think such a change (force the user to specify initialization or not) cou=
ld be made if</div><div>there was a=C2=A0big amount of uncontroversial data=
on issues that the current rules make easy to get into.</div>
<div>Also, if there is a way to easily point these issues once the change i=
s in place, then why not?</div><div><br></div><div>Basically, I don't t=
hink the initial proposal is a good idea, but disallowing implicit uninitia=
lization at all, and having an explicit way to specify=C2=A0uninitializatio=
n, would be good enough</div>
<div>for the compiler to point issues immediately, and would help code read=
ers too to understand the intent.=C2=A0</div><div>It appear to me to be mor=
e compatible with C++11 and previous C++ versions to do it that way.</div><=
div>
<br></div><div><br></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf301b67b3c82be704fc1167a1--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 18 Jun 2014 08:47:45 +0800
Raw View
--Apple-Mail=_D46EE844-22B9-418F-BDD3-13AF010D4C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-18, at 8:33 AM, Michael McLaughlin <mikebmcl@gmail.com> wrote:
> I think there's a way forward here that could improve things without chan=
ging the status quo.
> =20
> Consider the following hypothetical pseudo-proposal:
>=20
> - Add a syntax to explicitly specify that a variable should not be initia=
lized (e.g. "int x =3D void; float z[100000] =3D void;" - why " =3D void"? =
void is already reserved and can't legally be used like that now so it seem=
s like a good candidate).
> - Add some language to clearly specify that the existing C/C++03/C++11/C+=
+14 behavior (i.e. "int x; float z[100000];" means uninitialized) is the de=
fault behavior. Then state that a conforming implementation can give users =
the option to explicitly opt-in to a different behavior. The intent being t=
hat compiler switches (or defining some macro or whatever the implementer w=
ants to do) can change that, but that the user doesn't need to do anything =
different to keep the existing uninitialized behavior.
New syntax isn't required to select between different conforming behaviors.=
An [[uninitialized]] attribute should do the trick. Let it have the effect=
of disabling any compiler-specific warning that a trivially-constructible =
object is default-initialized.
Remember that it's still legal to use undifferentiated memory from malloc a=
s any trivially-constructible type. Your proposal protects against uninitia=
lized variables that are declared, but not against ones from new-expression=
s or merely willed into existence by casts.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_D46EE844-22B9-418F-BDD3-13AF010D4C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>On 2014–06&=
ndash;18, at 8:33 AM, Michael McLaughlin <<a href=3D"mailto:mikebmcl@gma=
il.com">mikebmcl@gmail.com</a>> wrote:</div><div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>I think th=
ere's a way forward here that could improve things without changi=
ng the status quo.</div><div> </div><div>Consider the following hypoth=
etical pseudo-proposal:</div><div><br></div><div>- Add a syntax to exp=
licitly specify that a variable should not be initialized (e.g. "int x =3D =
void; float z[100000] =3D void;" - why " =3D void"? void is =
already reserved and can't legally be used like that now so it seems like a=
good candidate).</div>
<div>- Add some language to clearly specify that the ex=
isting C/C++03/C++11/C++14 behavior (i.e. "int x; float z[100000]=
;" means uninitialized) is the default behavior. Then state =
that a conforming implementation can give users the option to explicitly op=
t-in to a different behavior. The intent being that compiler switches (or d=
efining some macro or whatever the implementer wants to do) can change=
that, but that the user doesn't need to do anything different to keep the =
existing uninitialized behavior.</div>
</div></blockquote></div><br><div><div>New syntax isn’t required to s=
elect between different conforming behaviors. An <font face=3D"Courier">[[u=
ninitialized]]</font> attribute should do the trick. Let it have the effect=
of disabling any compiler-specific warning that a trivially-constructible =
object is default-initialized.</div><div><br></div><div>Remember that it&rs=
quo;s still legal to use undifferentiated memory from <font face=3D"Courier=
">malloc</font> as any trivially-constructible type. Your proposal pro=
tects against uninitialized variables that are declared, but not against on=
es from new-expressions or merely willed into existence by casts.</div><br>=
<div></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_D46EE844-22B9-418F-BDD3-13AF010D4C7E--
.
Author: walter1234 <walter2bz@gmail.com>
Date: Tue, 17 Jun 2014 18:09:43 -0700 (PDT)
Raw View
------=_Part_35_9288025.1403053783354
Content-Type: text/plain; charset=UTF-8
IMO C++ philosophy is "don't pay for what you don't use" : initialisation
is a cost, it should be possible to express the fact you can reserve space
without initialising it;
I have encountered a situation where extraneous initialisation was a
problem (dealing with an in-order CPU with very severe pipeline and cache
hazards)
The solution is better compiler warnings.
Rust is interesting, it has safe semantics , and benefits from "every block
is an expression" so its' easier to re-arrange code to keep everything
initialised - but it doesn't guarantee that it can always match C++ for
performance. (only 'performance is as high as possible without violating
safety).
So before changing C++ to guarantee things are initialised, I would say
you'd need to copy this feature.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_35_9288025.1403053783354
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">IMO C++ philosophy is "don't pay for what you don't use" :=
initialisation is a cost, it should be possible to express the fact you ca=
n reserve space without initialising it;<div>I have encountered a situation=
where extraneous initialisation was a problem (dealing with an in-order CP=
U with very severe pipeline and cache hazards)<br><div><br><div>The solutio=
n is better compiler warnings.</div></div><div><br></div><div>Rust is inter=
esting, it has safe semantics , and benefits from "every block is an expres=
sion" so its' easier to re-arrange code to keep everything initialised - bu=
t it doesn't guarantee that it can always match C++ for performance. (only =
'performance is as high as possible without violating safety).</div></div><=
div><br></div><div>So before changing C++ to guarantee things are initialis=
ed, I would say you'd need to copy this feature.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_35_9288025.1403053783354--
.
Author: rouslankorneychuk@gmail.com
Date: Tue, 17 Jun 2014 18:39:25 -0700 (PDT)
Raw View
------=_Part_2286_10788703.1403055565906
Content-Type: text/plain; charset=UTF-8
I don't see how default initialization will actually prevent any bugs. If a
program reads a variable sooner than intended, or if the variable was not
assigned a value when it was intended, your program still does the wrong
thing regardless of whether the variable was initialized. The only
difference is the program behaves more predictably and therefore easier to
debug, but you can get the same predictability by compiling in debug mode.
This might even make certain bugs harder to find because a program that
would otherwise seemingly fail at random might not exhibit any symptoms
until it is run under a very specific set of conditions.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2286_10788703.1403055565906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't see how default initialization will actually preve=
nt any bugs. If a program reads a variable sooner than intended, or if the =
variable was not assigned a value when it was intended, your program still =
does the wrong thing regardless of whether the variable was initialized. Th=
e only difference is the program behaves more predictably and therefore eas=
ier to debug, but you can get the same predictability by compiling in debug=
mode. This might even make certain bugs harder to find because a program t=
hat would otherwise seemingly fail at random might not exhibit any symptoms=
until it is run under a very specific set of conditions.<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2286_10788703.1403055565906--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Wed, 18 Jun 2014 09:30:51 +0100
Raw View
--bcaec508f1daf9a6ca04fc181359
Content-Type: text/plain; charset=UTF-8
On 17 Jun 2014 16:49, "Matthew Fioravante" <fmatthew5876@gmail.com> wrote:
>
> This is going to be controversial, but lets get into it.
>
> The fact that `int x;` creates an uninitialized integer instead of a
default initialized one is completely wrong. I consider it a major defect
in the language, a bug in the standard.
If you really care about this, I would recommend figuring out how to add
this feature to clang/LLVM, and come back with benchmarks. Without those,
this is a non-starter.
Chris
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--bcaec508f1daf9a6ca04fc181359
Content-Type: text/html; charset=UTF-8
<p dir="ltr"><br>
On 17 Jun 2014 16:49, "Matthew Fioravante" <<a href="mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:<br>
><br>
> This is going to be controversial, but lets get into it.<br>
><br>
> The fact that `int x;` creates an uninitialized integer instead of a default initialized one is completely wrong. I consider it a major defect in the language, a bug in the standard.</p>
<p dir="ltr">If you really care about this, I would recommend figuring out how to add this feature to clang/LLVM, and come back with benchmarks. Without those, this is a non-starter.</p>
<p dir="ltr">Chris</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--bcaec508f1daf9a6ca04fc181359--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Wed, 18 Jun 2014 13:36:26 -0700
Raw View
On 6/17/14, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 June 2014 17:49, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>> Please now, convince if you can why this is a bad idea.
>>
>
> Because IMO the correct answer is that the default should be for requiring
> users to explicitly initialize the variable, and have a way to mark it the
> few times they want an uninitialized variable. All initializing to zero
> does is move the problem from something that static analyzers can catch to
> something they can't.
Emphasized.
If every declaration or expression has a fully-defined behavior, then, to
the compiler/runtime, no program can be wrong. Undefined behavior is your
friend. It means that your program can be detectably wrong. It helps
compilers help you find bugs.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 18 Jun 2014 14:44:01 -0700 (PDT)
Raw View
------=_Part_45_588973.1403127841237
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 17, 2014 5:49:57 PM UTC+2, Matthew Fioravante wrote:
>
> The fact that `int x;` creates an uninitialized integer instead of a
> default initialized one is completely wrong. I consider it a major defect
> in the language, a bug in the standard.
>
Have you requested your compiler vendor for a warning for uninitialized
variables? Shouldn't be too hard, 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_45_588973.1403127841237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 17, 2014 5:49:57 PM UTC+2, Matthew Fiorav=
ante 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">Th=
e fact that `int x;` creates an uninitialized integer instead of a default =
initialized one is completely wrong. I consider it a major defect in the la=
nguage, a bug in the standard.<br></div></blockquote><div><br></div><div>Ha=
ve you requested your compiler vendor for a warning for uninitialized varia=
bles? Shouldn't be too hard, right?</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_45_588973.1403127841237--
.
Author: Krzysztof Ostrowski <freejazz@tlen.pl>
Date: Thu, 19 Jun 2014 09:33:52 -0700 (PDT)
Raw View
------=_Part_503_20055616.1403195632558
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Good point, initialisation of variables is good for "safety" (state is=20
known from the very beginning) but it may cost too much. Initialisation of=
=20
variables is done as in C - I think that's by C++ design.=20
Please have a look at the following snippet.=20
explicit struct S {};
typedef explicit int int_type;
int_type i; // error: explicit initialisation is required
static int_type; // OK - implicitly to 0
int i; // OK
S s; // error: explicit initialisation is required
static S s; // OK if S has default constructor, we have this already
This does not break backward compatibility and reuses "explicit" keyword to=
=20
identify types (not type instances, objects) that require explicit=20
initialisation.
--=20
Krzysztof
W dniu wtorek, 17 czerwca 2014 17:49:57 UTC+2 u=C5=BCytkownik Matthew Fiora=
vante=20
napisa=C5=82:
>
> This is going to be controversial, but lets get into it.
>
> The fact that `int x;` creates an uninitialized integer instead of a=20
> default initialized one is completely wrong. I consider it a major defect=
=20
> in the language, a bug in the standard.
>
> One of my favorite C++11 API's is the atomic API. The reason is that it=
=20
> does the right thing when it comes to correctness vs speed. By default, t=
he=20
> path of least resistance is to have everything sequentially consistent=20
> which is the safest but also slowest memory ordering. If you know what=20
> you're doing and need some speed, you can opt to use less safe orderings.=
=20
> Even better, every use of the less safe ordering is tagged right there in=
=20
> the source code (without a comment)! It really doesn't get much better th=
an=20
> that in terms of API design. It follows Scott Meyers maxim of "Making=20
> interfaces easy to use correctly and hard to use incorrectly" perfectly.
>
> Initialization in C++ is the exact opposite of this. The easiest thing to=
=20
> do is write bugs by forgetting to initialize things. How many of you have=
=20
> spent long debugging sessions only to track the source to an uninitialize=
d=20
> variable? Not only that, but initialization in C++ is a horrible mess. le=
ts=20
> look at the list:
>
> Default initialization
> Value Initialization
> Copy Initialization
> Direct Initialization
> Aggregate Initialization
> List initialization
> Reference Initialization
> Constant Initialization
>
> Do you know by memory how all of those work and their gotchas? I sure as=
=20
> hell don't and I pity the novice developer who tries. Do we need this lev=
el=20
> of complexity?
>
> Here is a sketch one possible way we could solve this problem:
>
> int x; //<-default initialized to 0
> int x =3D void; //<-uninitialized, I know what I'm doing
> volatile int x; //<-uninitialized, because we can't introduce=20
> additional writes to volatile variables or break existing device driver=
=20
> code.
>
> Like the atomic API, the default action is the safe action, with options=
=20
> to remove the restraints should you need it.
> What I'm suggesting is that everything be initialized by default. And yes=
=20
> that means all legacy code that flips the switch to use the next version =
of=20
> the C++ language. If someone has a compelling performance argument for=20
> leaving something uninitialized, the =3D void syntax is there for them.
>
> What are the advantages:
> 1) Safe by default, if someone does a statistical survey, I'm confident=
=20
> that after this change the average amount of time spent debugging C++ cod=
e=20
> will go down.
> 2) Dangerous places are marked (=3Dvoid) as such, bringing attention and=
=20
> carefully scrutiny by the person reading code.
> 3) Less boilerplate code. Particularly with constructors I don't have to=
=20
> write a bunch of stupid initialization code for my ints, floats, and=20
> pointers.
> 4) Initialization behavior matches static and global variables. One less=
=20
> "except when" for Herb Sutter to write about in GotW.
>
> Counter arguments:
> 1) This will slow down everyone's programs!
>
> No it won't. Compilers have been doing something called constant=20
> propagation for over 20 years.
>
> That is, this code:
>
> int x =3D 0;
> x =3D 1;
>
> Will be optimized to this:
> int x =3D 1;
>
> 2) This will break C compatibility!
>
> No it won't. extern "C" code will still have the old behavior. There is n=
o=20
> C breakage here. The data being passed to and from C code is still the=20
> same, regardless of whether or not it was initialized by the compiler.
>
> 3) Why do we need this? Compilers, static checkers, and debugging tools=
=20
> can detect uninitialized use!
>
> Not always, and these tools are not always available. For example valgrin=
d=20
> is unusable on large resource consuming code bases. Also, even if there i=
s=20
> a tool why am I wasting my time checking this crap? I'd rather not be abl=
e=20
> to easily write these bugs in the first place. Fix this and one *major*=
=20
> class of bugs in C++ go away forever.
>
> 4) It will break legacy code!
>
> In some cases yes, but lets take a deeper look at the possibilities here:
>
> There are legacy code bases with real uninitialized variable bugs in them=
=20
> today. Your company probably has 1 or 2 in their large code base and=20
> miraculously its still working fine. If all of the sudden these things ge=
t=20
> fixed, it may change the behavior of your program, causing a "bug" in the=
=20
> sense that production is now operating differently. What used to be=20
> undefined behavior just got defined. I don't see this as a huge problem. =
If=20
> you have bugs in your code they need to be fixed. Also I do not believe=
=20
> this is a good enough reason to continue the subpar status quo forever.
>
> Then there may be other cases, for example some kind of strange embedded=
=20
> code or device drivers. Perhaps you instantiate an object over top of a=
=20
> hardware memory address. If you are doing this, you are probably also=20
> marking your variables as volatile, and that as I proposed above is still=
=20
> uninitialized so you won't be affected.
>
> Maybe you're doing something really funky like putting your call stack on=
=20
> some special memory, and default initialization will cause additional=20
> writes which will cause your program to fail. If you're doing this kind =
of=20
> crazy low level stuff, then you should know enough to be able to fix your=
=20
> code. Also you will be now annotating these instances with =3D void or=20
> volatile and that has the additional benefit of saying in your code,=20
> without a comment "*hey I'm doing some funny stuff here with=20
> initialization*".
>
> 5) I'm so good I don't write these kinds of bugs
>
> Congratulations, good job. Your colleagues however do write these kind of=
=20
> bugs and will continue to do so until the end of time. Sometimes you may=
=20
> even get to debug for them.
>
> I really enjoy C++, for all of its warts. I believe unlike other language=
s=20
> which come and go, C++ has staying power and will be around and growing f=
or=20
> a long time. C++ is the fastest and most versatile language on the planet=
.. =20
> I don't see everyone jumping ship anytime soon for a complete rewrite=20
> language like D (sorry Andrei). We're stuck with C++, so lets make it a=
=20
> better language.
>
> Doing something like this would be huge. It would require a lot of=20
> analysis to get right. My simple idea of =3Dvoid (inspired from D, thanks=
=20
> Andrei) may not work in all cases and will need to be fleshed out further=
..
>
> Please now, convince if you can why this is a bad idea. Why should we=20
> continue to inflict wasted hours of debugging sessions for these kinds of=
=20
> silly easy to write bugs on the future of C++? Can you think of any=20
> possible reason uninitialized by default is good other than "maintaining=
=20
> legacy code".
>
>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_503_20055616.1403195632558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Good point, initialisation of variables is good for "s=
afety" (state is known from the very beginning) but it may cost too much. I=
nitialisation of variables is done as in C - I think that's by C++ design. =
<br><br>Please have a look at the following snippet. <br><br><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">explicit</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> S </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typedef</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">explicit</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> int_type</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>int_type i</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// error: explicit initialisatio=
n is required</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">sta=
tic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> int_ty=
pe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// OK - implicitly to 0</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// OK</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br>S s</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// error: explicit initialisation is required</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> S s</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// OK if S has default constructor, we have this already</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></cod=
e></div><br><br>This does not break backward compatibility and reuses "expl=
icit" keyword to identify types (not type instances, objects) that require =
explicit initialisation.<br><br>-- <br>Krzysztof<br><br><br>W dniu wtorek, =
17 czerwca 2014 17:49:57 UTC+2 u=C5=BCytkownik Matthew Fioravante napisa=C5=
=82:<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">This is g=
oing to be controversial, but lets get into it.<br><br>The fact that `int x=
;` creates an uninitialized integer instead of a default initialized one is=
completely wrong. I consider it a major defect in the language, a bug in t=
he standard.<br><br>One of my favorite C++11 API's is the atomic API. The r=
eason is that it does the right thing when it comes to correctness vs speed=
.. By default, the path of least resistance is to have everything sequential=
ly consistent which is the safest but also slowest memory ordering. If you =
know what you're doing and need some speed, you can opt to use less safe or=
derings. Even better, every use of the less safe ordering is tagged right t=
here in the source code (without a comment)! It really doesn't get much bet=
ter than that in terms of API design. It follows Scott Meyers maxim of "Mak=
ing interfaces easy to use correctly and hard to use incorrectly" perfectly=
..<br><br>Initialization in C++ is the exact opposite of this. The easiest t=
hing to do is write bugs by forgetting to initialize things. How many of yo=
u have spent long debugging sessions only to track the source to an uniniti=
alized variable? Not only that, but initialization in C++ is a horrible mes=
s. lets look at the list:<br><br>Default initialization<br>Value Initializa=
tion<br>Copy Initialization<br>Direct Initialization<br>Aggregate Initializ=
ation<br>List initialization<br>Reference Initialization<br>Constant Initia=
lization<br><br>Do you know by memory how all of those work and their gotch=
as? I sure as hell don't and I pity the novice developer who tries. Do we n=
eed this level of complexity?<br><br>Here is a sketch one possible way we c=
ould solve this problem:<br><br> int x; //<-default in=
itialized to 0<br> int x =3D void; //<-uninitialized, =
I know what I'm doing<br> volatile int x; //<-uninitia=
lized, because we can't introduce additional writes to volatile variables o=
r break existing device driver code.<br><br>Like the atomic API, the defaul=
t action is the safe action, with options to remove the restraints should y=
ou need it.<br>What I'm suggesting is that everything be initialized by def=
ault. And yes that means all legacy code that flips the switch to use the n=
ext version of the C++ language. If someone has a compelling performance ar=
gument for leaving something uninitialized, the =3D void syntax is there fo=
r them.<br><br>What are the advantages:<br>1) Safe by default, if someone d=
oes a statistical survey, I'm confident that after this change the average =
amount of time spent debugging C++ code will go down.<br>2) Dangerous place=
s are marked (=3Dvoid) as such, bringing attention and carefully scrutiny b=
y the person reading code.<br>3) Less boilerplate code. Particularly with c=
onstructors I don't have to write a bunch of stupid initialization code for=
my ints, floats, and pointers.<br>4) Initialization behavior matches stati=
c and global variables. One less "except when" for Herb Sutter to write abo=
ut in GotW.<br><br>Counter arguments:<br>1) This will slow down everyone's =
programs!<br><br>No it won't. Compilers have been doing something called co=
nstant propagation for over 20 years.<br><br>That is, this code:<br><br>&nb=
sp; int x =3D 0;<br> x =3D 1;<br><br>Will be =
optimized to this:<br> int x =3D 1;<br><br>2) This will b=
reak C compatibility!<br><br>No it won't. extern "C" code will still have t=
he old behavior. There is no C breakage here. The data being passed to and =
from C code is still the same, regardless of whether or not it was initiali=
zed by the compiler.<br><br>3) Why do we need this? Compilers, static check=
ers, and debugging tools can detect uninitialized use!<br><br>Not always, a=
nd these tools are not always available. For example valgrind is unusable o=
n large resource consuming code bases. Also, even if there is a tool why am=
I wasting my time checking this crap? I'd rather not be able to easily wri=
te these bugs in the first place. Fix this and one <b>major</b> class of bu=
gs in C++ go away forever.<br><br>4) It will break legacy code!<br><br>In s=
ome cases yes, but lets take a deeper look at the possibilities here:<br><b=
r>There are legacy code bases with real uninitialized variable bugs in them=
today. Your company probably has 1 or 2 in their large code base and mirac=
ulously its still working fine. If all of the sudden these things get fixed=
, it may change the behavior of your program, causing a "bug" in the sense =
that production is now operating differently. What used to be undefined beh=
avior just got defined. I don't see this as a huge problem. If you have bug=
s in your code they need to be fixed. Also I do not believe this is a good =
enough reason to continue the subpar status quo forever.<br><br>Then there =
may be other cases, for example some kind of strange embedded code or devic=
e drivers. Perhaps you instantiate an object over top of a hardware memory =
address. If you are doing this, you are probably also marking your variable=
s as volatile, and that as I proposed above is still uninitialized so you w=
on't be affected.<br><br>Maybe you're doing something really funky like put=
ting your call stack on some special memory, and default initialization wil=
l cause additional writes which will cause your program to fail. If y=
ou're doing this kind of crazy low level stuff, then you should know enough=
to be able to fix your code. Also you will be now annotating these instanc=
es with =3D void or volatile and that has the additional benefit of saying =
in your code, without a comment "<i>hey I'm doing some funny stuff here wit=
h initialization</i>".<br><br>5) I'm so good I don't write these kinds of b=
ugs<br><br>Congratulations, good job. Your colleagues however do write thes=
e kind of bugs and will continue to do so until the end of time. Sometimes =
you may even get to debug for them.<br><br>I really enjoy C++, for all of i=
ts warts. I believe unlike other languages which come and go, C++ has stayi=
ng power and will be around and growing for a long time. C++ is the fastest=
and most versatile language on the planet. I don't see everyone jump=
ing ship anytime soon for a complete rewrite language like D (sorry Andrei)=
.. We're stuck with C++, so lets make it a better language.<br><br>Doing som=
ething like this would be huge. It would require a lot of analysis to get r=
ight. My simple idea of =3Dvoid (inspired from D, thanks Andrei) may not wo=
rk in all cases and will need to be fleshed out further.<br><br>Please now,=
convince if you can why this is a bad idea. Why should we continue to infl=
ict wasted hours of debugging sessions for these kinds of silly easy to wri=
te bugs on the future of C++? Can you think of any possible reason uninitia=
lized by default is good other than "maintaining legacy code".<br><br><br><=
br></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_503_20055616.1403195632558--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 20 Jun 2014 22:20:26 +0200
Raw View
On Tue, Jun 17, 2014 at 09:20:13AM -0700, Jim Porter wrote:
> On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" Liber wrote:
> >
> > On 17 June 2014 17:49, Matthew Fioravante <fmatth...@gmail.com
> > <javascript:>> wrote:
> >
>
> > Plus, that ship has sailed with C a long, long time ago...
> >
>
> I think it would be reasonable to add the option
> explicit-non-initialization to the standard, e.g.
>
> int foo; // doesn't initialize
> int foo = __no_init__; // doesn't initialize
> int foo = 0; // initializes
That would probably require some way to detect explicit-non-initialization
in order to support
std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector with
// unspecified content
which seems like a natural extension if explicit non-initialization is
added to the language.
/MF
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Tue, 24 Jun 2014 07:51:34 -0700 (PDT)
Raw View
------=_Part_2205_3047765.1403621494932
Content-Type: text/plain; charset=UTF-8
I'll respond to all of the feedback later.
In the meantime, it looks like Scott Meyers had something to say about this
very subject in the first 10 minutes of this talk:
https://www.youtube.com/watch?v=48kP_Ssg2eY
On Friday, June 20, 2014 4:20:30 PM UTC-4, Magnus Fromreide wrote:
>
> On Tue, Jun 17, 2014 at 09:20:13AM -0700, Jim Porter wrote:
> > On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" Liber wrote:
> > >
> > > On 17 June 2014 17:49, Matthew Fioravante <fmatth...@gmail.com
> > > <javascript:>> wrote:
> > >
> >
> > > Plus, that ship has sailed with C a long, long time ago...
> > >
> >
> > I think it would be reasonable to add the option
> > explicit-non-initialization to the standard, e.g.
> >
> > int foo; // doesn't initialize
> > int foo = __no_init__; // doesn't initialize
> > int foo = 0; // initializes
>
> That would probably require some way to detect explicit-non-initialization
> in order to support
>
> std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector with
> // unspecified content
>
> which seems like a natural extension if explicit non-initialization is
> added to the language.
>
> /MF
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2205_3047765.1403621494932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'll respond to all of the feedback later.<br>In the meant=
ime, it looks like Scott Meyers had something to say about this very subjec=
t in the first 10 minutes of this talk:<br><br>https://www.youtube.com/watc=
h?v=3D48kP_Ssg2eY<br><br><br>On Friday, June 20, 2014 4:20:30 PM UTC-4, Mag=
nus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Ju=
n 17, 2014 at 09:20:13AM -0700, Jim Porter wrote:
<br>> On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" Liber wro=
te:
<br>> >
<br>> > On 17 June 2014 17:49, Matthew Fioravante <<a>fmatth...@gm=
ail.com</a>=20
<br>> > <javascript:>> wrote:
<br>> >
<br>>=20
<br>> > Plus, that ship has sailed with C a long, long time ago...
<br>> >
<br>>=20
<br>> I think it would be reasonable to add the option=20
<br>> explicit-non-initialization to the standard, e.g.
<br>>=20
<br>> int foo; // doesn't initialize
<br>> int foo =3D __no_init__; // doesn't initialize
<br>> int foo =3D 0; // initializes
<br>
<br>That would probably require some way to detect explicit-non-initializat=
ion
<br>in order to support
<br>
<br>std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector w=
ith
<br> &=
nbsp; =
// unspecified content
<br>
<br>which seems like a natural extension if explicit non-initialization is
<br>added to the language.
<br>
<br>/MF
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2205_3047765.1403621494932--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 30 Jun 2014 11:40:38 -0400
Raw View
--089e0160b42021952404fd0f7bb9
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 17, 2014 at 8:33 PM, Michael McLaughlin <mikebmcl@gmail.com>
wrote:
> I think there's a way forward here that could improve things without
> changing the status quo.
>
> Consider the following hypothetical pseudo-proposal:
>
> <... explicitly uninitialized...>
>
> -Mike
>
>
I agree with this direction, and don't think anything stronger (like
forcing initialization) would ever pass. (Also note that this does NOT
interfere with valgrind, sanitizers, etc)
In general, I'm all for being explicit. I'd also appreciate a way to
explicitly say "implicit" on constructors, and 'mutable' on non-const
member functions. I review a lot of code; whenever something is implicit,
I need to question whether it was intentional or not. :-(
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0160b42021952404fd0f7bb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jun 17, 2014 at 8:33 PM, Michael McLaughlin <span dir=3D"lt=
r"><<a href=3D"mailto:mikebmcl@gmail.com" target=3D"_blank">mikebmcl@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I t=
hink there's=C2=A0a way forward here that could=C2=A0improve things wit=
hout changing the status quo.</div>
<div>=C2=A0</div><div>Consider the following hypothetical pseudo-proposal:<=
/div><div><br></div><... explicitly uninitialized...><br></div><div d=
ir=3D"ltr">=C2=A0<div>-Mike</div><div><div class=3D"h5"><div>=C2=A0</div></=
div></div></div>
</blockquote><div><br></div><div>I agree with this direction, and don't=
think anything stronger (like forcing initialization) would ever pass. (Al=
so note that this does NOT interfere with valgrind, sanitizers, etc)<br>
<br>In general, I'm all for being explicit.=C2=A0 I'd also apprecia=
te a way to explicitly say "implicit"=C2=A0 on constructors, and =
'mutable' on non-const member functions.=C2=A0 I review a lot of co=
de;=C2=A0 whenever something is implicit, I need to question whether it was=
intentional or not.=C2=A0 :-(<br>
<br></div><div>Tony<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0160b42021952404fd0f7bb9--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 30 Jun 2014 23:52:34 +0800
Raw View
On 2014-06-21, at 4:20 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> That would probably require some way to detect explicit-non-initialization
> in order to support
>
> std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector with
> // unspecified content
>
> which seems like a natural extension if explicit non-initialization is
> added to the language.
__no_init__ (or uninitialized, or whatever) could be like nullptr, a sole value of its type.
A library-only solution (with conversion functions) would even be workable, but for the fact that you cannot copy an uninitialized object.
It sounds like a nice core language extension.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sun, 20 Jul 2014 21:00:51 -0700 (PDT)
Raw View
------=_Part_1726_159171850.1405915251688
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Why not just a std::noinit<T> wrapper?
std::vector<std::noinit<int>>; //Does not initialize contents on=20
construction
Then the non-initialization is documented and enforced by the type system.=
=20
Another option is a simple std::allocator implementation.
On Monday, June 30, 2014 11:52:45 AM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9321, at 4:20 AM, Magnus Fromreide <ma...@lysato=
r.liu.se=20
> <javascript:>> wrote:=20
>
> > That would probably require some way to detect=20
> explicit-non-initialization=20
> > in order to support=20
> >=20
> > std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector with=20
> > // unspecified content=20
> >=20
> > which seems like a natural extension if explicit non-initialization is=
=20
> > added to the language.=20
>
>
> __no_init__ (or uninitialized, or whatever) could be like nullptr, a sole=
=20
> value of its type.=20
>
> A library-only solution (with conversion functions) would even be=20
> workable, but for the fact that you cannot copy an uninitialized object.=
=20
>
> It sounds like a nice core language extension.=20
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1726_159171850.1405915251688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why not just a std::noinit<T> wrapper?<div><br></div=
><div>std::vector<std::noinit<int>>; //Does not initialize cont=
ents on construction</div><div><br></div><div>Then the non-initialization i=
s documented and enforced by the type system. Another option is a simple st=
d::allocator implementation.</div><div><br></div><div><br>On Monday, June 3=
0, 2014 11:52:45 AM UTC-4, David Krauss wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<br>On 2014=E2=80=9306=E2=80=9321, at 4:20 AM, Magnus Fromreide <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6wyCFwRYUS0J" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ma...@lysator.liu.se</a>> wrote:
<br>
<br>> That would probably require some way to detect explicit-non-initia=
lization
<br>> in order to support
<br>>=20
<br>> std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vec=
tor with
<br>> &nb=
sp; &=
nbsp; // unspecified content
<br>>=20
<br>> which seems like a natural extension if explicit non-initializatio=
n is
<br>> added to the language.
<br>
<br>
<br>__no_init__ (or uninitialized, or whatever) could be like nullptr, a so=
le value of its type.
<br>
<br>A library-only solution (with conversion functions) would even be worka=
ble, but for the fact that you cannot copy an uninitialized object.
<br>
<br>It sounds like a nice core language extension.
<br>
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1726_159171850.1405915251688--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Jul 2014 12:21:24 +0800
Raw View
--Apple-Mail=_C2289781-1CE1-44E4-B74F-BAD09E53C120
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-21, at 12:00 PM, Matthew Fioravante <fmatthew5876@gmail.com> wro=
te:
> Why not just a std::noinit<T> wrapper?
>=20
> std::vector<std::noinit<int>>; //Does not initialize contents on construc=
tion
>=20
> Then the non-initialization is documented and enforced by the type system=
..
Transparent wrappers are a can of worms.
If wrapping isn't needed, then you can already use std::aligned_storage. I =
mentioned this earlier in the thread.
The nice thing about a singular value std::uninitialized is that it's also =
guaranteed to propagate by the type system, but only to its own point of us=
e. And, it can be used for overloading. For classes, it would generally con=
vey the idea of "invalid until assignment or further initialization," and i=
t would be implemented by propagating uninitialized initializers to members=
.. A constructor overloaded on std::uninitialized_t, rather than the default=
constructor, would be the canonical way to write an ugly partial-initializ=
ation semantic.
> Another option is a simple std::allocator implementation.
That allocator could well be standardized. Here's an implementation I have =
lying around, but I don't think it was ever tested.
template< typename client >
struct default_construct_allocator : std::allocator< client > {
template< typename rebound, typename arg1, typename ... arg >
void construct( rebound * p, arg1 && a1, arg && ... a )
{ ::new ( static_cast< void * >( p ) ) rebound { std::forward< arg1 >( a1=
), std::forward< arg >( a ) ... }; }
=09
template< typename rebound >
void construct( rebound * p )
{ ::new ( static_cast< void * >( p ) ) rebound; }
=09
template< typename rebound >
struct rebind { typedef default_construct_allocator< rebound > other; };
};
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_C2289781-1CE1-44E4-B74F-BAD09E53C120
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–21, at 12:00 PM, Matthew Fioravante <<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><div dir=3D"ltr">Why not just a std::noinit<T> wrapper?<div><br=
></div><div>std::vector<std::noinit<int>>; //Does not initializ=
e contents on construction</div><div><br></div><div>Then the non-initializa=
tion is documented and enforced by the type system. </div></div></div></blo=
ckquote><div><br></div><div>Transparent wrappers are a can of worms.</div><=
div><br></div><div>If wrapping isn’t needed, then you can already use=
<font face=3D"Courier">std::aligned_storage</font>. I mentioned this earli=
er in the thread.</div><div><br></div><div>The nice thing about a singular =
value <font face=3D"Courier">std::uninitialized</font> is that it=
’s also guaranteed to propagate by the type system, but only to its o=
wn point of use. And, it can be used for overloading. For classes, it would=
generally convey the idea of “invalid until assignment or further in=
itialization,” and it would be implemented by propagating <font face=
=3D"Courier">uninitialized</font> initializers to members. A construct=
or overloaded on <font face=3D"Courier">std::uninitialized_t</font>, rather=
than the default constructor, would be the canonical way to write an ugly =
partial-initialization semantic.</div><br><blockquote type=3D"cite"><div st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;"><div dir=3D"ltr"><div>Another option is a simple std::allo=
cator implementation.</div></div></div></blockquote><div><br></div><div>Tha=
t allocator could well be standardized. Here’s an implementation I ha=
ve lying around, but I don’t think it was ever tested.</div><div><br>=
</div><div><div><font face=3D"Courier">template< typename client ></f=
ont></div><div><font face=3D"Courier">struct default_construct_allocator : =
std::allocator< client > {</font></div><div><font face=3D"Courier"><s=
pan class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>template<=
typename rebound, typename arg1, typename ... arg ></font></div><div><f=
ont face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>void construct( rebound * p, arg1 && a1, arg && =
.... a )</font></div><div><font face=3D"Courier"><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre"> </span>{ ::new ( static_cast< void * >=
;( p ) ) rebound { std::forward< arg1 >( a1 ), std::forward< arg &=
gt;( a ) ... }; }</font></div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre"><font face=3D"Courier"> </font></span></div><div><font fac=
e=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>template< typename rebound ></font></div><div><font face=3D"Couri=
er"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void c=
onstruct( rebound * p )</font></div><div><font face=3D"Courier"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{ ::new ( static_cas=
t< void * >( p ) ) rebound; }</font></div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"><font face=3D"Courier"> </font></span></=
div><div><font face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre"> </span>template< typename rebound ></font></div><div><=
font face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>struct rebind { typedef default_construct_allocator< rebound=
> other; };</font></div><div><font face=3D"Courier">};</font></div><div=
><br></div></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_C2289781-1CE1-44E4-B74F-BAD09E53C120--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 29 Jul 2014 09:45:29 -0400
Raw View
--001a1135637eab620f04ff5540e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
First problem with 'std::vector<std::noinit<T>>' is that it puts the
initialization on the type of the container. I would expect that, after
proper initialization, that vector can be used wherever a 'std::vector<T>'
can be used, but by conveying the fact that it is not initialized on
construction on the type this is blocked.
The idea of using a special value on the constructor lets this be a detail
of how the object is constructed, rather than a property of the object for
the whole lifetime.
David
On Mon, Jul 21, 2014 at 12:00 AM, Matthew Fioravante <fmatthew5876@gmail.co=
m
> wrote:
> Why not just a std::noinit<T> wrapper?
>
> std::vector<std::noinit<int>>; //Does not initialize contents on
> construction
>
> Then the non-initialization is documented and enforced by the type system=
..
> Another option is a simple std::allocator implementation.
>
>
> On Monday, June 30, 2014 11:52:45 AM UTC-4, David Krauss wrote:
>
>>
>> On 2014=E2=80=9306=E2=80=9321, at 4:20 AM, Magnus Fromreide <ma...@lysat=
or.liu.se>
>> wrote:
>>
>> > That would probably require some way to detect
>> explicit-non-initialization
>> > in order to support
>> >
>> > std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vector with
>> > // unspecified content
>> >
>> > which seems like a natural extension if explicit non-initialization is
>> > added to the language.
>>
>>
>> __no_init__ (or uninitialized, or whatever) could be like nullptr, a sol=
e
>> value of its type.
>>
>> A library-only solution (with conversion functions) would even be
>> workable, but for the fact that you cannot copy an uninitialized object.
>>
>> It sounds like a nice core language extension.
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1135637eab620f04ff5540e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">First problem with 'std::vector<std::noinit<T>=
;>' is that it puts the initialization on the type of the container.=
I would expect that, after proper initialization, that vector can be used =
wherever a 'std::vector<T>' can be used, but by conveying the=
fact that it is not initialized on construction on the type this is blocke=
d.<br>
<br>The idea of using a special value on the constructor lets this be a det=
ail of how the object is constructed, rather than a property of the object =
for the whole lifetime.<br><br>=C2=A0 =C2=A0David</div><div class=3D"gmail_=
extra"><br>
<br><div class=3D"gmail_quote">On Mon, Jul 21, 2014 at 12:00 AM, Matthew Fi=
oravante <span dir=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmail.com" ta=
rget=3D"_blank">fmatthew5876@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div dir=3D"ltr">Why not just a std::noinit<T> wrapper?<div><br></div=
><div>std::vector<std::noinit<int>>; //Does not initialize cont=
ents on construction</div><div><br></div><div>Then the non-initialization i=
s documented and enforced by the type system. Another option is a simple st=
d::allocator implementation.</div>
<div><br></div><div><br>On Monday, June 30, 2014 11:52:45 AM UTC-4, David K=
rauss wrote:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>On 2014=E2=80=9306=E2=80=9321, at 4:20 AM, Magnus Fromreide <<a>ma..=
..@lysator.liu.se</a>> wrote:
<br>
<br>> That would probably require some way to detect explicit-non-initia=
lization
<br>> in order to support
<br>>=20
<br>> std::vector<int> v(MEGABYTE, __no_init__); // a megabyte vec=
tor with
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 // unspecified content
<br>>=20
<br>> which seems like a natural extension if explicit non-initializatio=
n is
<br>> added to the language.
<br>
<br>
<br>__no_init__ (or uninitialized, or whatever) could be like nullptr, a so=
le value of its type.
<br>
<br>A library-only solution (with conversion functions) would even be worka=
ble, but for the fact that you cannot copy an uninitialized object.
<br>
<br>It sounds like a nice core language extension.
<br>
<br></blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135637eab620f04ff5540e4--
.