220 27883 <61bffb8a-6e83-40dd-81ab-9e7616b2ebce@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Stabilize the numeric types in all platforms Date: Mon, 22 Aug 2016 20:32:27 -0700 (PDT) Lines: 139 Approved: news@gmane.org Message-ID: <61bffb8a-6e83-40dd-81ab-9e7616b2ebce@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_823_1322058276.1471923147949" X-Trace: blaine.gmane.org 1471923154 18991 195.159.176.226 (23 Aug 2016 03:32:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2016 03:32:34 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBTEH566QKGQEUTPG5XY@isocpp.org Tue Aug 23 05:32:30 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bc2Rx-0004eN-OZ for gclcip-std-proposals@m.gmane.org; Tue, 23 Aug 2016 05:32:29 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id o1sf208670449qkd.3 for ; Mon, 22 Aug 2016 20:32:30 -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=U7oSawUqJHzKFKItG4U8AbdglsJiCdUBylcZng+aBZE=; b=jJA5O7yCm/Kncu41livqO22Jyddvs3pAzKzrWUU8dE2WmMDZPR7t2ld3lVFjHp4riN 8XdXqz/KS9Tl2ypkrau/OZYweZdNfF+d743re4vY9NnEcEA/RIKSIKoWOYnj/ta6rvo8 0ng53hYhSB9HpLm1jSzQxHa0nmNSsUzNmKm/izFVFf9fbfzHORwiq28mpdHzAk8d3pwg Eq/jSQVPbbpuG19cQ7s+Mo5XbQzm3duO2UcjJDYdzZJd+CjtcPDqzCjDMLNnk5rTwPhg jswOH9KA4IORUuwom/691aE0rHf53QPmRJA8aeC5ucT0Ey744DJoojfLcjDx0jTFzzT8 7vTg== 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=U7oSawUqJHzKFKItG4U8AbdglsJiCdUBylcZng+aBZE=; b=Zz11lmOcowN3t42MQs522OOXhEvKixpC5yLxzI3Ej6lNqMJwwpg5T6rrg3oMdglOJd mjzXwTqO0diXq3R3hQ5/M0GSpoOqR8inQritJBAcAZ16TlGhrw2eGRw/caerLPbnLdby HCRPLKGwlFkG5lC8Jjvy9NirI0jauAWAxVT+gcOFpftC29Oc7Pwjhp4erfc7JgPgkD7y gekRqkxkArtmKJjOHItXbLF/kahOGtkxWAhWWrFAU5tRUF+Q9Orxkoyz1aCUaxRLfRG5 /ggxS3NUVbB+CdppkZK1xjSzERwxDQQTkAQD+nEj5vXWOmATSx3Per98gIgSR3zPoIUH csxA== 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=U7oSawUqJHzKFKItG4U8AbdglsJiCdUBylcZng+aBZE=; b=Pn2rpm30PjguNu+A7cXNJrbmI2Fqye09SbEjzbEJ9ZpQnJkJ8uLAVgMjpaNaAkfH9l vDs6D8Ap9r3pGVt61cxgvJg1unfptmVwSUoCCJBny8GoQIx53NNWglfRttjzL45u3d+T ARGwqQb24LznYHc/A0dxya69lMkidGVJj73jJaE9AHqEGKAe75MJrWH9GgkkqdoMlYNQ /Mlq7Jh5J353B4oTI/kl9VKidFYP4nbs+d/TCf2gd+mInTprq8WIc+IpcMgIXV0kiK7Q wHS0UNf6EmxwKCeXcb1CbnX6W22RqzMQ4Jgo3jSIUkg6RPbHQ26uY0YxYYzUDF4So79h XIzA== X-Gm-Message-State: AEkoousb9aTsr3Cv/JQys9B04izFfc+IQpag5JThj5nSyAu3oOD5DofZyOeI5Z4wRRf2mg== X-Received: by 10.129.46.145 with SMTP id u139mr18258748ywu.11.1471923150142; Mon, 22 Aug 2016 20:32:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.19.194 with SMTP id 185ls4407118itz.20.gmail; Mon, 22 Aug 2016 20:32:28 -0700 (PDT) X-Received: by 10.36.127.195 with SMTP id r186mr548624itc.0.1471923148721; Mon, 22 Aug 2016 20:32:28 -0700 (PDT) In-Reply-To: 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:27883 Archived-At: ------=_Part_823_1322058276.1471923147949 Content-Type: multipart/alternative; boundary="----=_Part_824_498033313.1471923147950" ------=_Part_824_498033313.1471923147950 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2016=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC= +8=E4=B8=8B=E5=8D=889:20:49=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A > > I must ask if you ever actually think or such before posting proposals,= =20 > like whether there's a fundamental reason these things haven't been done= =20 > already. > > In this case it's because the basic types are meant to map efficiently to= =20 > the most appropriate types on the native platform. > This is not quite true now. The problem is how to keep "most appropriate". There is no guarantee,=20 literally and normatively. This leaves them useless for application=20 programmers in general. The worse things is they misleads programmers with= =20 wrong assumptions. In fact there might be multiple interpretations about "native", and the=20 programs need nothing of such assumptions. For example Win32 vs. Cygwin,=20 both can be not "native" enough comparing to underlying NT. Whether same=20 widths of integers used or not on such implementations has nothing to do=20 with conformance. (Even different implementations on such platforms will=20 probably choose types closer to those specified by the ISA spec, this is a= =20 detailed strategy of implementation rather than a general guarantee.) The= =20 sense of "appropriate" totally up to the particular implementation being=20 used. If an appropriate ABI is needed, it should always define exact integer=20 types elsewhere, rather then depending on the language specifications. Thus, except the type 'int' (which is needed by `main` and operator=20 overloading), keeping them is merely for compatibility. =20 > Just because you, me, and many other people use x64 does not mean that=20 > everyone else with different CPUs having different types and strengths mu= st=20 > be bent to our whim. > > And those who need them, have the exact-width typedefs, Don't like their= =20 > "uglies" names? Then make your own typedefs that wrap around them. > > The fundamental types will not be constrained to fixed widths just to fit= =20 > your aesthetic preferences, nor will the naming in the stdlib. > > Please think before proposing. > > --=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/61bffb8a-6e83-40dd-81ab-9e7616b2ebce%40isocpp.or= g. ------=_Part_824_498033313.1471923147950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=889:20:49=EF=BC=8CD. B.=E5=86=99= =E9=81=93=EF=BC=9A
I must ask if you ever actually think or such before posting prop= osals, like whether there's a fundamental reason these things haven'= ;t been done already.

In this case it's because the basic types = are meant to map efficiently to the most appropriate types on the native pl= atform.
This is not quite true now.

The= problem is how to keep "most appropriate". There is no guarantee= , literally and normatively. This leaves them useless for application progr= ammers in general. The worse things is they misleads programmers with wrong= assumptions.

In fact there might be multiple interpretations about = "native", and the programs need nothing of such assumptions. For = example Win32 vs. Cygwin, both can be not "native" enough compari= ng to underlying NT. Whether same widths of integers used or not on such im= plementations has nothing to do with conformance. (Even different implement= ations on such platforms will probably choose types closer to those specifi= ed by the ISA spec, this is a detailed strategy of implementation rather t= han a general guarantee.) The sense of "appropriate" totally up t= o the particular implementation being used.

If an appropriate ABI is= needed, it should always define exact integer types elsewhere, rather then= depending on the language specifications.

Thus, except the type = 9;int' (which is needed by `main` and operator overloading), keeping th= em is merely for compatibility.

=C2=A0
Just because you, me, and many o= ther people use x64 does not mean that everyone else with different CPUs ha= ving different types and strengths must be bent to our whim.

<= div>And those who need them, have the exact-width typedefs, Don't like = their "uglies" names? Then make your own typedefs that wrap aroun= d them.

The fundamental types will not be constrained to = fixed widths just to fit your aesthetic preferences, nor will the naming in= the stdlib.

Please think before proposing.

=

--
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/61bffb8a-6e83-40dd-81ab-9e7616b2ebce= %40isocpp.org.
------=_Part_824_498033313.1471923147950-- ------=_Part_823_1322058276.1471923147949-- .