220 11498 article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Tue, 17 Jun 2014 17:01:35 -0700 (PDT) Lines: 188 Approved: news@gmane.org Message-ID: References: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> <1673959.6KvSiLfFrv@tjmaciei-mobl4> <438c8d34-c59d-42b2-ac81-6053f3a15e92@isocpp.org> <2386503.Orhs6aKSHF@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_374_14567490.1403049695410" X-Trace: ger.gmane.org 1403049708 11446 80.91.229.3 (18 Jun 2014 00:01:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Jun 2014 00:01:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBYNNQOOQKGQEQOHF66I@isocpp.org Wed Jun 18 02:01:41 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wx3Jq-00031J-DT for gclcip-std-proposals@m.gmane.org; Wed, 18 Jun 2014 02:01:38 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id l6sf323388qcy.10 for ; Tue, 17 Jun 2014 17:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=5ZJY/+QlnJx6rbibs/PyDjEvsLlwQ3lnf7eNa/sUIqM=; b=GsIGEGupDRmm7A5XpWzF/BDppAagICzAuuL56dIC5L8yLI7/lCgnrkFrhOLPblkhm0 p1KXtNTJti8BXugPsuq4yf5sJuYiOc6c0qpTYVChvolhUEmXeZ98T5vdnl95NBrQ+yqG Yb8LV9TAONlVx8vJX7WPh8dSN1T7EoQcu7qyoY1T9hOSc6Ccps6dlMGV4CcNUOjHLxd8 AGjXkTOJVl/6uSIOogTHWcOwbf6A8iUwV00FG7olf62wrt9knrTdma0dcDyJP7x44WqI XxofWUljsmIGpQxojpjuoYeJ9+t05hQ6amicNQLgEGKlLgJvLzCNLYmIF5I/a2Vp6uFI 7XTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=5ZJY/+QlnJx6rbibs/PyDjEvsLlwQ3lnf7eNa/sUIqM=; b=EXfxqUdM1dcJRWejpE9tVhHjk1B8AGPlxP/7aZejpdJ8QYuMbS+M4uCAE3/zATCnsH 0sI3IHxuxG87PGTGhMu/hBRthxczDxuJkMkF0jzfFmGx7swH7GzzYKnDq6LBqu6pbfuQ 2ns5SHIJF0jKOhZ7x6Gxa3gwqO/j0rEVQKqISve94sdyRZrS8mD2YNu6GYH6KzhE337j QMT+5PwodVcGllDulNslLVnuCHCM8JsZ6uR3Qo6Vj8EuqkK0Yw8KkaGV2z+i+na9ArmZ 99iZulx3PgFdiq10lmxOhMNScXXEbNmE6/XbnXxYt6ZO0L8j4ZMlYRExomsDX+quWWB2 l+IA== X-Gm-Message-State: ALoCoQkjyVtPUzIUt4LGkX2bPCQAcI80VnF5IEcNkKuqEe0zUbQnDf8KdTqN16XTdbTwQaU4GnQu X-Received: by 10.236.144.136 with SMTP id n8mr229330yhj.22.1403049697627; Tue, 17 Jun 2014 17:01:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.111.197 with SMTP id ik5ls1963076igb.30.gmail; Tue, 17 Jun 2014 17:01:36 -0700 (PDT) X-Received: by 10.50.79.137 with SMTP id j9mr6925igx.6.1403049696880; Tue, 17 Jun 2014 17:01:36 -0700 (PDT) In-Reply-To: X-Original-Sender: gmisocpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11498 Archived-At: ------=_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 > 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 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]; Guy proposes default initialization. Get's offers of even less=20 initialization. Only in C++... --=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


On Wednesday, June 18, 2014 5:39:38 AM UTC+12, Kla= im - Jo=C3=ABl Lamotte wrote:
=


On Tue, Jun 17, 2014 at 6:59 PM= , Thiago Macieira <thi...@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 the
> 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 de= finitely
agree with you.

Changing C++ some 40 years after the fact (if we can include the C legacy) = is
a no-go.


Actually, I thin= k such a change (force the user to specify initialization or not) could be = made if
there was a big amount of uncontroversial data on is= sues that the current rules make easy to get into.
Also, if there is a way to easily point these issues once the change i= s in place, then why not?

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
for the compiler to point issues immediately, and would help code read= ers too to understand the intent. 
It appear to me to be mor= e compatible with C++11 and previous C++ versions to do it that way.
<= 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.
For instance.

class Person { ...= };
uninitialized  Person p; // Not interesting.
<= br>
template<T> class Optional { // Could simplify Optional= ?
   uninitialized T m_obj; // More interesting.
<= div>};

uninitliazed iostream stdin, stdout, stderr= ; // Complex initialization of global done later.

= uninitialized int x; // I'm not sure what I want yet, it's depending on the= path take, don't  warn me though.

Other type= s 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 anythi= ng. I just want to store this string. / it'll never grow.
c_api(&= amp;s);


Other out there ideas:

char* p =3D new uninitialized Person[100];

<ironic>Guy proposes default initialization. = Get's offers of even less initialization. Only in C++... </ironic>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_374_14567490.1403049695410-- .