220 28051 <2e027e3a-4b4c-47e4-b6a2-f03e23c7e480@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Stabilize the numeric types in all platforms Date: Tue, 30 Aug 2016 05:15:00 -0700 (PDT) Lines: 242 Approved: news@gmane.org Message-ID: <2e027e3a-4b4c-47e4-b6a2-f03e23c7e480@isocpp.org> References: <1706311.trY4MaExHO@tjmaciei-mobl1> <36958399-1282-4cef-a12b-0439e176aeda@isocpp.org> <7777451.RoO7Qxo2g3@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1764_1623985175.1472559300959" X-Trace: blaine.gmane.org 1472559313 4964 195.159.176.226 (30 Aug 2016 12:15:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 12:15:13 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBRXRSW7AKGQEXOHDJZI@isocpp.org Tue Aug 30 14:15:07 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1behwU-0000WA-Us for gclcip-std-proposals@m.gmane.org; Tue, 30 Aug 2016 14:15:03 +0200 Original-Received: by mail-pf0-f200.google.com with SMTP id 63sf41124726pfx.0 for ; Tue, 30 Aug 2016 05:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=aAEh/QujKHoX3TDEFNrFhYRYoYuhxgn9PAKeE+cGTZQ=; b=wyA4B7NwBMIcIow0HLnbaJwcqdfki2P0l+4PNaAcMLXHcwkxMoh3qzvCTHUhWChohj C3I2KPAsDlJ7BSNP/4wbUQI3G4/VMFhG6o6PAY4o0QxMSXtMEIXxe9Te0y5sIZCtj/bv BW2sDWeXwVICbjLLkeVWeQc09/JGHdwRDOsLqCWlCGp15Uny2CGmFA0wH/JzpTHN17m9 73ohP+S9B3SD0m6SMhAUKZpxrnm7mFKjk9iCs4sjxz6kU5Kk0qBI+AeAAFahN7Ml1R+W gItBbxlxGkERnyKHPdTfV/xeL1oKCS1mJjrgrQBYNcbp6lrZXAo89a7QoXIbHa9+6B1n 3nuA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=aAEh/QujKHoX3TDEFNrFhYRYoYuhxgn9PAKeE+cGTZQ=; b=n+D4baGsw018SHFVUY5jSbNr+NZVXy8Lfa+Wagu5nqZs409SXtuyzC53rrLAHIsODP 7q9neCQGi5v9rby0WfW4GRWm5ngQPjyeA16kkoVocNOpg5dS81KLDS3bW25HfO/wgEbv MirlpL9EEtCGS0hVu20W5k5Fjmi5lsxMtommABouIgy1VFdpHgkgwUXxPyLbWnrafScB OSaNa33uA0wzrxJnCkF0Ij+CoA932FXsr7EFeq+WEJV0rHX7lCjG7WCRxAWOhjzIQf3q HPBayKgSLIFkaNVK6wp+ZjAJIeimBCW/+9DgeH+GuruZhjzvpZVayofb+B+j6NRxr2qx MnWQ== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=aAEh/QujKHoX3TDEFNrFhYRYoYuhxgn9PAKeE+cGTZQ=; b=ItC885eC8z/gXy11kGbt8mPB/LjOon7p/OYWecqcV4mWF79leEvMsE1lHICEyW9FPv pkcS0LxP0hPEUQ7uuQoZDlyt6OIRuOSv/f5HDDwOJR5/1Pj4vW1jJpjkLkymP2eWQoQS yyHSB01pNvYl9Ym964sJkE6zDSQXd44IAYgRQVWATuB8Ubs0bj3ju8k/TFn3FA4d3Vr/ DqTk9uT3EOPEToaIbQIEVYPJrRPOdIgcMTtc6DLIy+7LF9TplUyAlGJGxyQu64hJZxqz KCk/5sqNtBg2OscecMu4uGJKG/5XM2W0+2O3H/EGZnp/TIpqMEn0gpDGfyhROcv8BV2s MUTA== X-Gm-Message-State: AE9vXwOvnse4FDIwX2AjFzvLYJE5SZec/gPvs7GQTI5eX3qQXJdTrJZeawX6YySO491Q2A== X-Received: by 10.98.28.133 with SMTP id c127mr2654809pfc.2.1472559303534; Tue, 30 Aug 2016 05:15:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.88.1 with SMTP id f1ls1094004itb.19.gmail; Tue, 30 Aug 2016 05:15:02 -0700 (PDT) X-Received: by 10.36.34.194 with SMTP id o185mr530112ito.6.1472559301967; Tue, 30 Aug 2016 05:15:01 -0700 (PDT) In-Reply-To: <7777451.RoO7Qxo2g3@tjmaciei-mobl1> X-Original-Sender: frankhb1989@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:28051 Archived-At: ------=_Part_1764_1623985175.1472559300959 Content-Type: multipart/alternative; boundary="----=_Part_1765_873464785.1472559300959" ------=_Part_1765_873464785.1472559300959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC= +8=E4=B8=8B=E5=8D=8810:45:52=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF= =BC=9A > > On ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:= =20 > > Good point about 2's complements. However, all of these are what I have= =20 > > already known. I still wonder why these (at least partially) width-awar= e=20 > > types are not in the core language while traditional fundamental intege= r=20 > > types are still in it. In a systemic view of design, this is an=20 > > inappropriate inversion of abstraction layers -- all implementations in= =20 > > reality build these fundamental types on some integer types with known= =20 > > width provided by underlying specification, or just with the width=20 > > specified artificially. Since we always will have some exact width=20 > integers=20 > > in the stacks of implementation, why not lift the uncertainty to the=20 > higher=20 > > level? Though I don't think declaring `short` or `long` by users very= =20 > > useful, but it gives us an opportunity to have the core language=20 > cleaner,=20 > > with less confusion, meeting better to the principle of zero-cost=20 > > abstraction mentally, and being a little easier to implement.=20 > > Or perhaps better keeping them all out of the core language?=20 > > Like Nicol said, I don't see what the issue is about having to #include= =20 > something before you can use the types. I find that having the exact-widt= h=20 > types *not* be reserved keywords is a better option, because it won't=20 > break=20 > code that has myNS::int32_t, nor code that was ABI-dependent but fully=20 > valid=20 > that defined (and defines) int32_t in the global namespace.=20 > > Actually I don't much care about the #include stuff. Keeping fixed-with= =20 types away with hard-coded keywords also sounds better to me, though ABI=20 issues here are only caused by historical reasons -- e.g. if we does not=20 have them in current language, we would probably not reserve mangled=20 encoding for troublesome things like `unsigned long`, so many problems=20 would not exist at all. However, I care why the so-called "fundamental" types *are there* even=20 there are nothing good reasons to use them? And, why not change, besides=20 the compatibility issues? =20 > Moreover, as we've said time and again, the exact-width integer types=20 > aren't=20 > required to exist in all implementations. Your statement saying "we will= =20 > always have some exact width integers" is incorrect. So what's the point= =20 > of=20 > having a reserved word that can't be used?=20 > > No. I did not mean the type of the C++ language, but the fixed-width=20 integer notions in *the whole stack* of the implementation, including ABI= =20 references like ISA spec, and internal specification of hardware design,=20 etc. Since you can't physically implement "unspecified" width effectively,= =20 you have to know at least one of the exact widths. That width is then *eras= ed=20 *in some high level language like C and C++ before you recover it in a even= =20 higher abstraction. It is a waste of effort on leaking abstraction. BTW, I wish fixed-with integer type with certain strategies (2's=20 complement, wrapping behavior, UB or not on overflow, etc) mandated some=20 day, at least on hosted implementations, as BS put arbitrarily-width=20 integer type in the wishlist of standardization (IIRC). =20 > You may not think that using short or long is very useful, but others may= =20 > disagree with you. I personally agree partially and disagree on other=20 > parts.=20 > More to the point, changing the fundamental integer types now is a simple= =20 > non-=20 > starter. Leave them alone.=20 > > It is still arguable what is deserved to be true "fundamental", before=20 they are proposed to be changed. =20 > --=20 > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 > Software Architect - Intel Open Source Technology Center=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/2e027e3a-4b4c-47e4-b6a2-f03e23c7e480%40isocpp.or= g. ------=_Part_1765_873464785.1472559300959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:45:52=EF=BC=8CThiago Maciei= ra=E5=86=99=E9=81=93=EF=BC=9A
O= n ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:
> Good point about 2's complements. However, all of these are wh= at I have=20
> already known. I still wonder why these (at least partially) width= -aware=20
> types are not in the core language while traditional fundamental i= nteger=20
> types are still in it. In a systemic view of design, this is an=20
> inappropriate inversion of abstraction layers -- all implementatio= ns in=20
> reality build these fundamental types on some integer types with k= nown=20
> width provided by underlying specification, or just with the width= =20
> specified artificially. Since we always will have some exact width= integers=20
> in the stacks of implementation, why not lift the uncertainty to t= he higher
> level? Though I don't think declaring `short` or `long` by use= rs very
> useful, but it gives us an opportunity to have the core language c= leaner,
> with less confusion, meeting better to the principle of zero-cost
> abstraction mentally, and being a little easier to implement.
> Or perhaps better keeping them all out of the core language?

Like Nicol said, I don't see what the issue is about having to #inc= lude=20
something before you can use the types. I find that having the exact-wi= dth=20
types *not* be reserved keywords is a better option, because it won'= ;t break=20
code that has myNS::int32_t, nor code that was ABI-dependent but fully = valid=20
that defined (and defines) int32_t in the global namespace.

Actually I don't much care about the #include stu= ff. Keeping fixed-with types away with hard-coded keywords also sounds bett= er to me, though ABI issues here are only caused by historical reasons -- e= ..g. if we does not have them in current language, we would probably not res= erve mangled encoding for troublesome things like `unsigned long`, so many = problems would not exist at all.

However, I care why the so-called &= quot;fundamental" types are there even there are nothing good r= easons to use them? And, why not change, besides the compatibility issues?<= br>=C2=A0
Moreover, a= s we've said time and again, the exact-width integer types aren't= =20
required to exist in all implementations. Your statement saying "w= e will=20
always have some exact width integers" is incorrect. So what's= the point of=20
having a reserved word that can't be used?

No. I did not mean the type of the C++ language, but = the fixed-width integer notions in the whole stack of the implementa= tion, including ABI references like ISA spec, and internal specification of= hardware design, etc. Since you can't physically implement "unspe= cified" width effectively, you have to know at least one of the exact = widths. That width is then erased in some high level language like C= and C++ before you recover it in a even higher abstraction. It is a waste = of effort on leaking abstraction.

BTW, I wish fixed-with integer typ= e with certain strategies (2's complement, wrapping behavior, UB or not= on overflow, etc) mandated some day, at least on hosted implementations, a= s BS put arbitrarily-width integer type in the wishlist of standardization = (IIRC).
=C2=A0
You= may not think that using short or long is very useful, but others may=20
disagree with you. I personally agree partially and disagree on other p= arts.=20
More to the point, changing the fundamental integer types now is a simp= le non-
starter. Leave them alone.

It is still arguable what is deserved to be true &quo= t;fundamental", before they are proposed to be changed.
=C2=A0
<= /div>
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/2e027e3a-4b4c-47e4-b6a2-f03e23c7e480= %40isocpp.org.
------=_Part_1765_873464785.1472559300959-- ------=_Part_1764_1623985175.1472559300959-- .