220 27882 article Path: news.gmane.org!.POSTED!not-for-mail From: Ren Industries Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Stabilize the numeric types in all platforms Date: Mon, 22 Aug 2016 22:56:45 -0400 Lines: 134 Approved: news@gmane.org Message-ID: References: <0d61be1e-2020-4f09-baa6-64dca463cb68@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c028c4b540a7053ab4504f X-Trace: blaine.gmane.org 1471921020 13915 195.159.176.226 (23 Aug 2016 02:57:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2016 02:57:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDILF3OBTACRB3XW526QKGQE622OF4Y@isocpp.org Tue Aug 23 04:56:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f71.google.com ([209.85.214.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bc1tP-0002qa-66 for gclcip-std-proposals@m.gmane.org; Tue, 23 Aug 2016 04:56:47 +0200 Original-Received: by mail-it0-f71.google.com with SMTP id f6sf23900732ith.2 for ; Mon, 22 Aug 2016 19:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=Ilsd3cIvmxgHGbobOgEv/FJxq2M4y4fUPKbU2Aiu1nc=; b=StocVC0Nx5nuLiYYlm63aKOWHfFAwz8XJ+nTwqNddqcrMwP/d+VoomfCdYCg5tXV6I w+5LlR0NDw777Khl4CenSmN7v5DuNxDK6BHBueSWI7rWb+i2pYX9MX8sljDSrPN3Te4F GJs8RPwXTqXLGT4SLU8GSmdl1jrNolbuiwdu9Lrv2Na5zvcW2WTakD763a+NF/VUbYro jLlD5qLBZcSrqgOvVEhpVvdCeZ03ktqZa7ONSOOsF+ipx1XY+arwdrubO7uyW7v2LKLR iNugW2x7980ux0Jx6Cvyh9hWKg2ToUhTYOD2Jrpa3gEuwjgUhAEV4+sw31Aw0iCKYFNT KOqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Ilsd3cIvmxgHGbobOgEv/FJxq2M4y4fUPKbU2Aiu1nc=; b=VbXIUOo8qi72nMI1sLIGPkUGFDTyQgQCUp27U8BXtxjl1EiKVU7qeIbdWZ2skTUQFu h1o4XNW8sTsIDNX2oLx1M4k6UZjqG5ZNrt8Yk33GdthOD7A+KduHXkWozUiBU/2Sysch pvJy7VQgBA1GUO19u+FYUkktcsnayEJoaoHnIwqC8KCywKSiYU8JG8eINOMN7WLE8peJ 4NrCkaYd+N6bS+dmwxKdGKAriUfF27PyuKeWnnEBWhAa6tZce9noDX9gnFvus/rbi3t+ jIYVMmCjKy85nSoIDyigmh93Zfxg/h7mPhRWHCm22inDY0aAEJf5BA2uvt/We6qQWlCj reew== X-Gm-Message-State: AEkoouvOOhx7BPMoQ/V44A3UtAezJCWpTQcrODi1lKa1vuOuPkWetTL5vXRABfzj52ZUSQ== X-Received: by 10.107.7.149 with SMTP id g21mr19170741ioi.11.1471921007566; Mon, 22 Aug 2016 19:56:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.31.42 with SMTP id x39ls9336460otd.44.gmail; Mon, 22 Aug 2016 19:56:46 -0700 (PDT) X-Received: by 10.202.232.13 with SMTP id f13mr14823644oih.94.1471921006619; Mon, 22 Aug 2016 19:56:46 -0700 (PDT) Original-Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com. [2607:f8b0:4003:c06::22d]) by mx.google.com with ESMTPS id j124si478349oib.65.2016.08.22.19.56.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 19:56:46 -0700 (PDT) Received-SPF: pass (google.com: domain of renindustries@gmail.com designates 2607:f8b0:4003:c06::22d as permitted sender) client-ip=2607:f8b0:4003:c06::22d; Original-Received: by mail-oi0-x22d.google.com with SMTP id f189so178966883oig.3 for ; Mon, 22 Aug 2016 19:56:46 -0700 (PDT) X-Received: by 10.157.63.131 with SMTP id r3mr15482789otc.66.1471921006130; Mon, 22 Aug 2016 19:56:46 -0700 (PDT) Original-Received: by 10.202.75.207 with HTTP; Mon, 22 Aug 2016 19:56:45 -0700 (PDT) In-Reply-To: <0d61be1e-2020-4f09-baa6-64dca463cb68@isocpp.org> X-Original-Sender: RenIndustries@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of renindustries@gmail.com designates 2607:f8b0:4003:c06::22d as permitted sender) smtp.mailfrom=renindustries@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:27882 Archived-At: --001a11c028c4b540a7053ab4504f Content-Type: text/plain; charset=UTF-8 Yes, *what if another platform is 16 bit? *How in the world are we to change that platform so it supports 32 bit ints? All the currently working code would break, and for a lot of legacy systems the actual code might be gone. Even if everyone had the source code to every program, many programs may *depend* on int being 16 bits. The code might not make sense using 32 bit integers. For example, some DSP's are still 16 bit; emulating 32 bits on 16 bit processors will more than half the speed of the code. And much code on these sorts of units is time critical; they might not have that many cycles to spare. Finally, the fundamental meaning of "int" would change; int would no longer be the natural size for the platform. So why the hell are we calling it int anymore? It's a 32 bit integer, not a platform neutral integer. Either we need to name it more strictly (such as int32_t or something) or we need to give a new name to "platform neutral" integer or "most natural" integer or "fastest" integer. Maybe intnatural? natural? fixed? Do any of those really strike you as a good idea? No? That's why this is a non-starter. On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer wrote: > My proposal is to fix the size (the table is only a example). > It's only because the standard library never use the uglies types in > functions, classes and etc. > My proposal is to cross-platform programmer that need, for example > > uniform_int_distribution dist(10, numeric_limits::max()); // > assume int 32-bit > > use_new_number(dist(eng))); > > returning a 32-bit integer. What if in another platform int is 16-bit? > What if is needled use a std function that requires a int? The value will > be truncated in that 32-bit platform. > > > -- > 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 > email 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/0d61be1e-2020-4f09- > baa6-64dca463cb68%40isocpp.org > > . > -- 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 email 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/CAMD6iD9TuK5jV9BFHoAa%2BmNCR608bEP%2BrmbV67Mw3PbO1EvDsA%40mail.gmail.com. --001a11c028c4b540a7053ab4504f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, what if another platform is 16 bit? How in the= world are we to change that platform so it supports 32 bit ints?
All t= he currently working code would break, and for a lot of legacy systems the = actual code might be gone.

Even if everyone had th= e source code to every program, many programs may depend=C2=A0on int= being 16 bits.
The code might not make sense using 32 bit intege= rs. For example, some DSP's are still 16 bit; emulating 32 bits on 16 b= it processors will more than half the speed of the code. And much code on t= hese sorts of units is time critical; they might not have that many cycles = to spare.

Finally, the fundamental meaning of &quo= t;int" would change; int would no longer be the natural size for the p= latform. So why the hell are we calling it int anymore? It's a 32 bit i= nteger, not a platform neutral integer. Either we need to name it more stri= ctly (such as int32_t or something) or we need to give a new name to "= platform neutral" integer or "most natural" integer or "= ;fastest" integer. Maybe intnatural? natural? fixed?

Do any of those really strike you as a good idea? No?
Tha= t's why this is a non-starter.
On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer <rodrigojose690@gmail.com> wrote:
My proposal is to fix the size (the table is= only a example).
It's only because the standard library never use = the uglies =C2=A0types in functions, classes and etc.
My proposal= is to cross-platform programmer that need, for example

uniform_int_distribution<int> dist(10, numeric_limits<int>= ;::max()); // assume int 32-bit

use_new_number(dis= t(eng)));
=C2=A0
returning a 32-bit integer. What if in= another platform int is 16-bit? What if is needled use a std function that= requires a int? The value will be truncated in that 32-bit platform.
=


--
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-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/0d61= be1e-2020-4f09-baa6-64dca463cb68%40isocpp.org.

--
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/CAMD6iD9TuK5j= V9BFHoAa%2BmNCR608bEP%2BrmbV67Mw3PbO1EvDsA%40mail.gmail.com.
--001a11c028c4b540a7053ab4504f-- .