220 11502 <3A9B04D2-9D20-4344-95FC-9BA1ED9E602B@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Wed, 18 Jun 2014 09:17:58 +0800 Lines: 99 Approved: news@gmane.org Message-ID: <3A9B04D2-9D20-4344-95FC-9BA1ED9E602B@gmail.com> References: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> <52d66b4b-a634-4e51-bdb5-5f6e188c01a8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_13379618-54A7-4FEE-8CAE-FD6EA3492C15" X-Trace: ger.gmane.org 1403054294 26583 80.91.229.3 (18 Jun 2014 01:18:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Jun 2014 01:18:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBSWRQOOQKGQE5IJPZ7I@isocpp.org Wed Jun 18 03:18:05 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wx4Vn-0006cI-VX for gclcip-std-proposals@m.gmane.org; Wed, 18 Jun 2014 03:18:04 +0200 Original-Received: by mail-oa0-f72.google.com with SMTP id eb12sf1272957oac.3 for ; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=SKj6MLyp6zYBz2NWTHSUrFnKdiexAvpoUN7XXDRIevo=; b=ROi/FbEe78kfj1Yj0P2K0bg9XtQ/O2pQ7VXo2EH+l1n+5Wzprd1usq4MmjKcRas0Wr p4ekOjzmo27SmRNMPrKcmdkPXQWInqzxxDoIpMnMIa+svTSQEIB+fnTKkoW50NGUD6UZ JvK/N8rCxx+5zq1OAUGm4Z4vOh3Q0HlwMi4WTVdmkF4z+52GbBhCz84GIoXN9yooZV3m VWI0b8gOqYSsxT7MyA0wrdJTxl8WOQ7a5Fk3ceZT3pGKRslOQF2rs2GW+yZJ8Jt4o492 MqM9LSMGobjYUZ6qIPL20Tz4TX+7S5OkemboOY9CFbTptGGbu24u+HiBNcL6gulDzJhF nYJA== X-Gm-Message-State: ALoCoQl2RGK5CWSEDf/acgRKKbZrVcGWuAPcUk3RoIgnXzLAqA67s0PbDnPLaxTShxzSSGxCXeQA X-Received: by 10.50.32.4 with SMTP id e4mr167997igi.7.1403054282764; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.176.134 with SMTP id ci6ls1895857igc.22.canary; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) X-Received: by 10.50.131.132 with SMTP id om4mr412572igb.14.1403054282270; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) Original-Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [2607:f8b0:4001:c03::233]) by mx.google.com with ESMTPS id e10si450293ico.47.2014.06.17.18.18.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 18:18:02 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::233 as permitted sender) client-ip=2607:f8b0:4001:c03::233; Original-Received: by mail-ie0-f179.google.com with SMTP id tr6so126075ieb.24 for ; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) X-Received: by 10.50.20.33 with SMTP id k1mr792274ige.26.1403054282123; Tue, 17 Jun 2014 18:18:02 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.157]) by mx.google.com with ESMTPSA id g2sm33845073igc.12.2014.06.17.18.18.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 18:18:01 -0700 (PDT) In-Reply-To: <52d66b4b-a634-4e51-bdb5-5f6e188c01a8@isocpp.org> X-Mailer: Apple Mail (2.1878.2) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::233 as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:11502 Archived-At: --Apple-Mail=_13379618-54A7-4FEE-8CAE-FD6EA3492C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-06-18, at 9:09 AM, walter1234 wrote: > IMO C++ philosophy is "don't pay for what you don't use" : initialisation= is a cost, it should be possible to express the fact you can reserve space= without initialising it; std::aligned_storage does this. > I have encountered a situation where extraneous initialisation was a prob= lem (dealing with an in-order CPU with very severe pipeline and cache hazar= ds) >=20 > The solution is better compiler warnings. Agreed. > Rust is interesting, it has safe semantics , and benefits from "every blo= ck is an expression" so its' easier to re-arrange code to keep everything i= nitialised - but it doesn't guarantee that it can always match C++ for perf= ormance. (only 'performance is as high as possible without violating safety= ). >=20 > So before changing C++ to guarantee things are initialised, I would say y= ou'd need to copy this feature. I've not more than glanced at Rust, and don't plan to, so perhaps you could= elaborate. Treating statements as expressions is common to many languages,= but I don't see the relevance. Do you mean, rather than an if-else stateme= nt, the language prefers something more like the ternary operator (perhaps= with tuple un/packing), such that it tends to keep account of the assignme= nts and you won't forget one? --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --Apple-Mail=_13379618-54A7-4FEE-8CAE-FD6EA3492C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;06–18, at 9:09 AM, walter1234 <walter2bz@gmail.com> wrote:

IMO C++ philosoph= y is "don't pay for what you don't use" : initialisation is a cost, it shou= ld be possible to express the fact you can reserve space without initialisi= ng it;

std::al= igned_storage does this.

I have encountered a situation where extraneous initialisatio= n was a problem (dealing with an in-order CPU with very severe pipeline and= cache hazards)

The solution is better compiler warnings.<= /div>

Agreed.

Rust is interesting, it = has safe semantics , and benefits from "every block is an expression" so it= s' easier to re-arrange code to keep everything initialised - but it doesn'= t guarantee that it can always match C++ for performance. (only 'performanc= e is as high as possible without violating safety).

So before changing C++ to guarantee things are initialised, I would= say you'd need to copy this feature.

I’ve not more than glanced at Rust, and don’t plan to, = so perhaps you could elaborate. Treating statements as expressions is commo= n to many languages, but I don’t see the relevance. Do you mean, rath= er than an if-else statement, the language prefers something more like &nbs= p;the ternary operator (perhaps with tuple un/packing), such that it tends = to keep account of the assignments and you won’t forget one?

=

--

---
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>.
--Apple-Mail=_13379618-54A7-4FEE-8CAE-FD6EA3492C15-- .