220 26436 <8990a523-99a1-4f36-be6a-9cd6f9495176@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: iswalpha and locales Date: Mon, 27 Jun 2016 10:54:17 -0700 (PDT) Lines: 131 Approved: news@gmane.org Message-ID: <8990a523-99a1-4f36-be6a-9cd6f9495176@isocpp.org> References: <5057e854-b2ea-4c39-81c7-367bc3e54080@isocpp.org> <5458114.SXJFP9uSZR@tjmaciei-mobl1> <7091420.GCog6ZeHg6@tjmaciei-mobl1> <7f783407-0c3c-4381-a852-dfd12bc450d1@isocpp.org> <84d2b9e6-a29b-4c79-8646-2f00dbc5087b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5236_423458830.1467050057636" X-Trace: ger.gmane.org 1467050060 14636 80.91.229.3 (27 Jun 2016 17:54:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jun 2016 17:54:20 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBSWQYW5QKGQERPBGPNY@isocpp.org Mon Jun 27 19:54:20 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bHajj-0007AH-U6 for gclcip-std-proposals@m.gmane.org; Mon, 27 Jun 2016 19:54:20 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id r136sf212764458qke.2 for ; Mon, 27 Jun 2016 10:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=VBEw2aDp68kreJHi0P/GQ/S1F7aBj5Lowm7d1otgOzQ=; b=zcWVsa8pr1nqHeDyn735m7gLIoPMBcVMkM1OiPkAg6Qqa+4VXFKeCs60bHPnpcUWrU wSItINx/h/YEsA3xwR0fxUSZgekSD17D5eaQHs4lu7zW7at5Wr8KerKw684Nb1/4WmIn I1SvBWn/7Ryo1lPmeaQ1W/HzqCqKQvaBe6YGyL/+67WGKdmmSlmdCaG4JVJP1zS7Y7gZ 1Su8yRwYo0lIsWjjffKppqZR70Ng8qxHG5M4GQ0flaxNlaeyNVYs2EfC5U38x4YaQahz MFbg0a/Wsby0L2BLHrq2xF8+RoN7c10o6S6PT3zuPy3JXbIpiQsgS8ni/RhS3yE/a54D 6BUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=VBEw2aDp68kreJHi0P/GQ/S1F7aBj5Lowm7d1otgOzQ=; b=x/XbaVohnw0cPTN1O4mKm28BBpJqMTBIOf9Ao5IuomiCI2Iu0q5ErMjtmdlGZA+c1J M7mE5lre62EyTpDyA22k0zUpctxqrPupioZwgE6MR4U2k28KaOfexlr1KgcWm9UYRPXa 4gXl3RqvJ0XHy+VicVmQ4vNkajhDhgPM8rGtZjwvaYBGSlTg/MbUHATOaceAJkHkj90n 2afd4BJMEXn0InYGg671c1aG8s3so33XP2yQKdlXIocGdp+6f0WgxdN7vfcvIEcSnUj7 mvahJhPz/WuEhRRgZcoG2Mp8VBKLH+ASXsas1vyL/oWwIsfHLWHNKfHgHxLmiHPp14Rc Uufw== 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:cc: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=VBEw2aDp68kreJHi0P/GQ/S1F7aBj5Lowm7d1otgOzQ=; b=Dn301r1YcUQIZxPnlgHOXVKznkvMYEyBQpoeNuIcW0pBPOAau33dK/vVhCXRnG5xaQ fenW3w4mZ2B/erItB5aV+KJm551Mq3zWPI3qFtQ5I7Iycvg9uhubwX+kLatPGuhmtLTI o7HPuY5mg81a3qk5CyKENLnB12HjE9njnmnszDUeDYmT+zDSUaX6CO0zw9qzPj99+ZEO 3FCh8KWWq8gZyzY+zC9tru2LWvkF8sf0WzaQwFRh9yVCQuFoO6V9TrSxiKNWkdV7kBi9 rzzpN6NOQRG2xQn50Rqkhf4eDh529qkykD0r1aoCrioQTpOmA9K89V4FwbY19D4i80Nb CjfA== X-Gm-Message-State: ALyK8tKMat84D6SuQARm8EL5DR9nXMrgKq7MY9LRg+a9fUcpOoJtxGBMggzOS3CeuUvfAw== X-Received: by 10.237.43.129 with SMTP id e1mr18630006qtd.0.1467050059155; Mon, 27 Jun 2016 10:54:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.214 with SMTP id 83ls4248568ios.1.gmail; Mon, 27 Jun 2016 10:54:18 -0700 (PDT) X-Received: by 10.36.57.15 with SMTP id l15mr277852ita.7.1467050058154; Mon, 27 Jun 2016 10:54:18 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:26436 Archived-At: ------=_Part_5236_423458830.1467050057636 Content-Type: multipart/alternative; boundary="----=_Part_5237_427801698.1467050057636" ------=_Part_5237_427801698.1467050057636 Content-Type: text/plain; charset=UTF-8 On Monday, June 27, 2016 at 11:27:29 AM UTC-4, Matthew Woehlke wrote: > > On 2016-06-27 11:11, Matthew Woehlke wrote: > > On 2016-06-25 20:04, Nicol Bolas wrote: > >> ... Have you looked at the Unicode tables? They are not small. Like I > said, > >> there are ways to make them smaller (and your code makes them far > bigger > >> than necessary, since only ~15% of the codepoint range is assigned). > But > >> there is no proof-of-concept that shows that it won't bloat executables > by > >> 100KB. > > > > Huh? Why on earth would you bake the tables into the executable ROM? Any > > sane implementation is going to store them in shared memory. > > > > For grins, I wrote a simple test program that calls 'iswalpha' on its > > argument... it is 8618 bytes. (For comparison, I wrote a program that > > does NOTHING AT ALL, and it is 8455 bytes. That's a difference of... 163 > > bytes. Hardly 100 KiB.) > > Okay, clarification... yes, you need to store the data *somewhere*. So I > guess you are talking specifically about OS-less embedded platforms > where the executable - including statically linked standard library - is > possibly the only thing on the device. > It's not just that. If an application statically links to the standard library, there's no reason for it to be loading the Unicode table at runtime. > I'd argue that Unicode support should not be required for freestanding > implementations. (How many people on tiny embedded systems are dealing > with Unicode, anyway?) That seems to solve the problem neatly... > Well, the standard already has such requirements. Freestanding implementations can omit most of the standard library, providing only support for most of Chapter 18, the type traits from 20.10, and the atomics. If even isn't a requirement, I see no reason why Unicode operations would be. -- 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/8990a523-99a1-4f36-be6a-9cd6f9495176%40isocpp.org. ------=_Part_5237_427801698.1467050057636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, June 27, 2016 at 11:27:29 AM UTC-4, Mat= thew Woehlke wrote:
On 2016-06-= 27 11:11, Matthew Woehlke wrote:
> On 2016-06-25 20:04, Nicol Bolas wrote:
>> ... Have you looked at the Unicode tables? They are not small.= Like I said,=20
>> there are ways to make them smaller (and your code makes them = far bigger=20
>> than necessary, since only ~15% of the codepoint range is assi= gned). But=20
>> there is no proof-of-concept that shows that it won't bloa= t executables by=20
>> 100KB.
>=20
> Huh? Why on earth would you bake the tables into the executable RO= M? Any
> sane implementation is going to store them in shared memory.
>=20
> For grins, I wrote a simple test program that calls 'iswalpha&= #39; on its
> argument... it is 8618 bytes. (For comparison, I wrote a program t= hat
> does NOTHING AT ALL, and it is 8455 bytes. That's a difference= of... 163
> bytes. Hardly 100 KiB.)

Okay, clarification... yes, you need to store the data *somewhere*. So = I
guess you are talking specifically about OS-less embedded platforms
where the executable - including statically linked standard library - i= s
possibly the only thing on the device.

It's not just that. If an application statica= lly links to the standard library, there's no reason for it to be loadi= ng the Unicode table at runtime.
=C2=A0
I'd argue that Unicode support should not be required for freestanding
implementations. (How many people on tiny embedded systems are dealing
with Unicode, anyway?) That seems to solve the problem neatly...

Well, the standard already has such requirements.= Freestanding implementations can omit most of the standard library, provid= ing only support for most of Chapter 18, the type traits from 20.10, and th= e atomics.

If even <string> isn't a requirement, I see no = reason why Unicode operations would be.

--
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/8990a523-99a1-4f36-be6a-9cd6f9495176= %40isocpp.org.
------=_Part_5237_427801698.1467050057636-- ------=_Part_5236_423458830.1467050057636-- .