220 17739 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Comments on N4424: inline variables Date: Fri, 08 May 2015 14:38:55 +0800 Lines: 218 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_F023BB05-1D4D-4322-A68F-F8D301B03452" X-Trace: ger.gmane.org 1431067170 15436 80.91.229.3 (8 May 2015 06:39:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 May 2015 06:39:30 +0000 (UTC) Cc: Hal Finkel , Richard Smith , "William M. (Mike) Miller" To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBAABBF5UWGVAKGQE3MCRMKA@isocpp.org Fri May 08 08:39:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YqbwP-0002IS-1m for gclcip-std-proposals@m.gmane.org; Fri, 08 May 2015 08:39:21 +0200 Original-Received: by obfe9 with SMTP id e9sf79433130obf.1 for ; Thu, 07 May 2015 23:39:19 -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:content-type:subject:date:message-id:cc:to :mime-version:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=aOeHUy/D3y1j5knUA50cdcT2J98vxN1PdTUs3FlXvNY=; b=GLuPJD5RtbKPp1MNkLw7b2q2Ga8TfYcme+rs6cWIGDWvVkzOF9pfLSTFQmNe67tJyd XxbPhoQi9pCiQbahk9nO/BKNFWympQVYvTgH9lQRKgVhtHV5GCXpY4Q2ZEMuiy2Fw9/Q edFerKPjL2NbsckW0uX4b68W9IShxmAQ0Enwj0GyckjH4MoaX4OhkMRzt+VfNph/qTuA Q7obpHu5u+Fvtnz2h3bWs1+kCda0mjkvIP+sxgvIdg2sComaBCympIsl5WwQnEhOxjP9 0cEwH4JwJYBDE2xIlHiDwUGx4pqqHFyuohJ9ZtuChnX2IyUDgfPbdti+HH5ZKAfQHUSN R4CQ== X-Gm-Message-State: ALoCoQntB1TaslzZ0OrO1cA58zilOTq9uoxlERvM/ceByrv/KtJPbFTo7FP0ZOhJJFMkT5wJGbgQ X-Received: by 10.42.12.208 with SMTP id z16mr3675850icz.18.1431067159763; Thu, 07 May 2015 23:39:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.37.143 with SMTP id l137ls854462iol.23.gmail; Thu, 07 May 2015 23:39:19 -0700 (PDT) X-Received: by 10.68.173.100 with SMTP id bj4mr3964625pbc.168.1431067158969; Thu, 07 May 2015 23:39:18 -0700 (PDT) Original-Received: from nk11p04mm-asmtp001.mac.com (nk11p04mm-asmtp001.mac.com. [17.158.236.236]) by mx.google.com with ESMTPS id ya6si5843715pab.179.2015.05.07.23.39.18 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 23:39:18 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@mac.com designates 17.158.236.236 as permitted sender) client-ip=17.158.236.236; Original-Received: from [172.20.10.2] (unknown [121.54.44.94]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NO0002FUQGWPF40@nk11p04mm-asmtp001.mac.com> for std-proposals@isocpp.org; Fri, 08 May 2015 06:39:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-08_03:2015-05-08,2015-05-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1505080089 X-Mailer: Apple Mail (2.2098) X-Original-Sender: potswa@mac.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@mac.com designates 17.158.236.236 as permitted sender) smtp.mail=potswa@mac.com; dmarc=pass (p=NONE dis=NONE) header.from=mac.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:17739 Archived-At: --Apple-Mail=_F023BB05-1D4D-4322-A68F-F8D301B03452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Sorry for the late message. This should be relevant to CWG. Regarding N4424, the main problem is not that there isn=E2=80=99t currently= a viable workaround, but that it doesn=E2=80=99t work very well due to oth= er deficiencies in the standard. Declarations with non-constant initializers in multiple TUs have unordered = dynamic initialization ([basic.start.init] =C2=A73.6.2/2). Such initializat= ion is unsequenced with respect to anything else that happens before entry = into main(). It=E2=80=99s UB to access such a variable from within another = initializer or any function called during startup. So, if two declarations use this new feature and one depends on the other, = it=E2=80=99s UB. If one global uses the feature and another doesn=E2=80=99t= , and there=E2=80=99s a dependency, it=E2=80=99s UB. I recall discussing the solution with Richard on this (std-proposals) list,= but its implementation may be nontrivial. The problem is that implementati= ons are allowed to use multiple threads to initialize TUs in parallel (the = order of initializations in one TU being well-defined). Assigning a sensibl= e order to unordered initializations then requires adding synchronization i= nto dynamic initialization subroutines. This synchronization would be just = the same as what=E2=80=99s already used for static local variables, but it= =E2=80=99s still something that needs to be implemented. (Implementation ma= y be simpler for single-threaded initialization, but the standardese needs = to cover all implementations.) Checking the Wiki, concern over synchronization was raised in EWG by Bjarne= and others. =E2=80=94=E2=80=94=E2=80=94 If the proposal doesn=E2=80=99t make it into C++17, or even if it does, her= e=E2=80=99s a simpler alternative just for constexpr. The motivating problem is most urgent (UB in the standard library!) and eas= iest to solve for objects with static initialization. Why not fix externall= y-linked constexpr variables, without adding any new syntax? Let extern con= stexpr indicate vague linkage. This isn=E2=80=99t a breaking change, since any program that declares a var= iable as extern constexpr in two TUs is currently ill-formed. Non-constexpr= but extern declarations may still occur in other TUs, although they are se= ldom used. Some programmers care about multiple-definition diagnostics; this functiona= lity could be restored with a little extra implementation. Current linkers = avoid comparing function bodies byte-by-byte, but such is reasonable for ob= ject representations of constexpr objects. Anyway, this issue is intrinsic = to solving the problem, and the alternative is near-certain ODR violation. It fits with the current meaning of extern which is simply that the variabl= e is shared between TUs. Users can easily apply the solution without thinki= ng about a new inline feature, but only considering that the implicit stati= c is problematic. Actually I started writing such a proposal before deciding to go with my ow= n inline variables paper instead. I should have pursued both in parallel. A= lthough various interpretations of the inline keyword can extrapolate corre= ct semantics for shared constexpr variables, there=E2=80=99s no reason to d= epend on anything contentious, or to preserve the brokenness of extern cons= texpr. Let inline constexpr and extern constexpr mean the same thing, and d= on=E2=80=99t make users wait for their implementation to get around to inli= ne. (For that matter, don=E2=80=99t forget that inline needs to override the im= plicit static bestowed by constexpr! I don=E2=80=99t see this in the propos= ed standardese.) =E2=80=94=E2=80=94=E2=80=94 Just as an aside for folks following along, here is a fleshed-out workaroun= d. All of this goes into a header, and it causes make_side_effects to be ca= lled at startup if it=E2=80=99s included anywhere =E2=80=94 but when it=E2= =80=99s called might be anytime from first-thing to just-before-main. The t= ype foo is insignificant, it might be int or anything. template< typename =3D void > struct wrap_global { static foo thing; }; template< typename t > foo wrap_global< t >::thing =3D make_side_effects(); static_assert( & wrap_global<>::thing, "" ); // Require object to exist, al= ong with its definition. --=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=_F023BB05-1D4D-4322-A68F-F8D301B03452 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
So= rry for the late message. This should be relevant to CWG.

Regarding N4424, the main proble= m is not that there isn=E2=80=99t currently a viable workaround, but that i= t doesn=E2=80=99t work very well due to other deficiencies in the standard.=

Declarations wit= h non-constant initializers in multiple TUs have unordered dynamic initiali= zation ([basic.start.init] =C2=A73.6.2/2). Such initialization is unsequenc= ed with respect to anything else that happens before entry into main(). It=E2=80=99s UB to access such a var= iable from within another initializer or any function called during startup= ..

So, if two decl= arations use this new feature and one depends on the other, it=E2=80=99s UB= .. If one global uses the feature and another doesn=E2=80=99t, and there=E2= =80=99s a dependency, it=E2=80=99s UB.

=
I recall discussing the solution with Richard on this= (std-proposals) list, but its implementation may be nontrivial. The proble= m is that implementations are allowed to use multiple threads to initialize= TUs in parallel (the order of initializations in one TU being well-defined= ). Assigning a sensible order to unordered initializations then requires ad= ding synchronization into dynamic initialization subroutines. This synchron= ization would be just the same as what=E2=80=99s already used for static lo= cal variables, but it=E2=80=99s still something that needs to be implemente= d. (Implementation may be simpler for single-threaded initialization, but t= he standardese needs to cover all implementations.)
Checking the Wiki, conce= rn over synchronization was raised in EWG by Bjarne and others.
=

=E2=80=94=E2=80=94=E2= =80=94
If the proposal doesn=E2=80=99t make it into C+= +17, or even if it does, here=E2=80=99s a simpler alternative just for = ;constexpr.
<= div class=3D"">
The motivating problem = is most urgent (UB in the standard library!) and easiest to solve for objec= ts with static initialization. Why not fix externally-linked constexpr vari= ables, without adding any new syntax? Let extern constexpr indicate vague linkage.

This isn=E2=80=99t a breaking ch= ange, since any program that declares a variable as extern constexpr in two TUs is currently ill-fo= rmed. Non-constexpr but = extern declarations may still= occur in other TUs, although they are seldom used.
Some programmers care about multiple-def= inition diagnostics; this functionality could be restored with a little ext= ra implementation. Current linkers avoid comparing function bodies byte-by-= byte, but such is reasonable for object representations of constexpr object= s. Anyway, this issue is intrinsic to solving the problem, and the alternat= ive is near-certain ODR violation.

It fits with the current meaning of extern which is simply that th= e variable is shared between TUs. Users can easily apply the solution witho= ut thinking about a new inline feature, but only considering that the implicit static is problematic.
=
Actually I started writing such a prop= osal before deciding to go with my own inline variables paper ins= tead. I should have pursued both in parallel. Although various interpretati= ons of the inline keywor= d can extrapolate correct semantics for shared constexpr variables, there=E2=80=99s no reason to de= pend on anything contentious, or to preserve the brokenness of extern constexpr. Let inline constexpr and extern constexpr mean the same thing, and don=E2=80=99t make users= wait for their implementation to get around to inline.

=
(For that matter, don=E2=80=99t forget that inline needs to override the implicit static bestowed by constexpr! I don=E2=80=99t see this in the proposed standar= dese.)

=E2=80=94= =E2=80=94=E2=80=94
Just as an aside for folks followin= g along, here is a fleshed-out workaround. All of this goes into a header, = and it causes make_side_effects to= be called at startup if it=E2=80=99s included anywhere =E2=80=94 but when it=E2=80=99s called might be anytime from first-thin= g to just-before-main. The type foo is insignificant, it might be int or anything.

te= mplate< typename =3D void >
struct wrap_global {
    static foo thing;
};

template< typename t >
foo wrap_global&= lt; t >::thing =3D make_side_effects();

<= font face=3D"Courier" class=3D"">static_assert( & wrap_global<>::= thing, "" ); // Require object to exist, along with its definition.<= /div>

--

---
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=_F023BB05-1D4D-4322-A68F-F8D301B03452-- .