220 33011 <25d8a3a1-1712-4bc1-9a3a-c7fd2b67b119@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why are there no standardized string manipulation algorithms ? Date: Wed, 28 Jun 2017 17:47:42 -0700 (PDT) Lines: 167 Approved: news@gmane.org Message-ID: <25d8a3a1-1712-4bc1-9a3a-c7fd2b67b119@isocpp.org> References: <02cf02f4-df2e-4eb0-adcf-a7d167cd7e56@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2804_553728615.1498697262415" X-Trace: blaine.gmane.org 1498697265 18687 195.159.176.226 (29 Jun 2017 00:47:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 00:47:45 +0000 (UTC) Cc: george.h.personal@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBL442HFAKGQEVMNZXDQ@isocpp.org Thu Jun 29 02:47:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQNcR-0004a1-CO for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 02:47:39 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id c13sf55825429ywa.13 for ; Wed, 28 Jun 2017 17:47:45 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=749qUyuJUFdr37BHb8C3qmC174KbP0aQCzU4KcCMD2s=; b=LIIlSgAPxIWkcl/sqi6lFtfQ++wxAORoyjRwRyVeSdXjWKWL693r34bTWG1VglIlnr xJBmHPFsIVMeP3yMJ5yLCK3o7vAw4ZJ14diKj5OG4wrzK6OzuK1STvQfNAJH9CMlJj8y ynN0QZXfWR7Su+magpUC/TWIMor32Ssb1g5frPvdrP8QLGGE3NnELhJ1WNvA+rolK1mY UWDfGWBUJm31ZmNNe+vo5FaV/jTZ/EGHmKjwRAvY0ytXm7FfoX5nf6KkKtgevLwnBWvY OK7ZjiG1DdxJtHCMfF17tVCggs7T0oxArv6O44kGFZDil/LGeQCZaXFf5ssz74Wbk7yF y6VA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=749qUyuJUFdr37BHb8C3qmC174KbP0aQCzU4KcCMD2s=; b=Dvy/cj4q2NdSWGNPPEgCVzjlyyst09ENSAcd8xI4e0QBM1WN5FvxOCBT55Ks4vrjBX vBO7VSB/HGQXQ64l3t9KfXHlis6TC6WGLTIuGuTVfgNAQs/Y5+bCXcbmX1GqfPrkDr/J J83Uu1FtlGWu2Lx5XMt13xJPnBo3Hf6JXs8SfPMdr/KoI4aQAjGgCS5hP7r7Qf7DoGbx 4ya8+EnxCapptA6+BXBEU2DXP9ngov8jd/gMHYN8CdTRmW4fjugyW7j+JmYuFdsaiGa1 RmpK/Kx+9b+FRkoZgYqxGyJEnp0OqZmqjFESQPgjEy4oZBXi5fBlKQxBprbgIjcJ2Vmm 8+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=749qUyuJUFdr37BHb8C3qmC174KbP0aQCzU4KcCMD2s=; b=AyADAgWaidQX5Zo9nR67L8nHObLBKUnm/0tyMzwoy3UJ1LDxwc7JpzsGKVA8NT3qEK AQzD7TeihdPg9ISUpLQw5A10ZX7tMenl1nd4dhg3xQm5QQAQvVp9rzJTZ3FG3Q4JZbed MvqddSriFlMNtZ18mPMFMHZfd2yrEf4+wry6uJRffUFHERdk0KwkVGQ0Mp8l5FRI3Ioc C/ehH6Kxyr/P7pdUQJyoSjvoDiQNFoMlZDxWQViXjv95hLna1RTydH8ydbwIjbuzrM2A UTEcVvkq5p0mZfsyesLu6U/6DqJYUGXG/t0vFliaSHlCRXx4NXvWJEOFsGl00R3OxS6M fO3w== X-Gm-Message-State: AKS2vOzIu6+oQED5XqLQtX1hR0fgNN0YDQiELEx1cbFhqmFRKvWACi/y z0KxhcNJG8nRPe6F X-Received: by 10.129.163.209 with SMTP id a200mr8367825ywh.95.1498697264479; Wed, 28 Jun 2017 17:47:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.47.204 with SMTP id j195ls3525829itj.7.gmail; Wed, 28 Jun 2017 17:47:42 -0700 (PDT) X-Received: by 10.36.88.206 with SMTP id f197mr258507itb.10.1498697262898; Wed, 28 Jun 2017 17:47:42 -0700 (PDT) In-Reply-To: <02cf02f4-df2e-4eb0-adcf-a7d167cd7e56@isocpp.org> X-Original-Sender: jmckesson@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:33011 Archived-At: ------=_Part_2804_553728615.1498697262415 Content-Type: multipart/alternative; boundary="----=_Part_2805_890549700.1498697262415" ------=_Part_2805_890549700.1498697262415 Content-Type: text/plain; charset="UTF-8" On Wednesday, June 28, 2017 at 6:48:56 PM UTC-4, george.h...@gmail.com wrote: > > I assume the biggest argument against more diverse string manipulation > functions would be that strings are a container and, as such, most common > string related algorithms can be implemented with the algorithms library. > > I feel like the biggest hurdle by far when presenting C++ to a new person > is the fact that I have to come up with an excuse for why the language > doesn't have basic string manipulation that they'd expect it to have and > tell them the alternative is to either use boost (and that opens up another > can of worms) or write their own. I also bet that there are a metric ton of > bugs out there that come as a result of poorly implemented string > processing functions (e.g. implementations of to lower case that aren't > compatible with unicode). I feel like having something like: > > void std::to_lowercase(std::string& str); > > void std::to_uppercase(std::string& str); > > void std::string_replace(std::string& str, std::string pattern, > std::string replacement); > > void std::trim_right(std::string& str, std::string pattern = " "); > > void std::trim(std::string& str, std::string pattern = " "); > > void std::trim_left(std::string& str, std::string pattern = " "); > > bool std::string_contains(std::string& str, std::string str); //(arguably > this isn't need when we have find, but I still have to read the > documentation to understand how to use find, in this case the func > signature is enough to understand how to use it) > Ignoring the question of how to implement them, these are not algorithms. As you have written them, there is no reason not to make them member functions of `std::string`. They don't even work with `basic_string`s of non-`char` types, let along something like `string_view` or any other string container/range. The whole point of STL algorithms is that they are *uncoupled* from the container on which they operate. Your "algorithms" are specific to the container. Those aren't algorithms; they're just namespace-scoped functions. .... There's probably a dozen more necessary algorithm I haven't thought of. > I think they would be all easy to implement, to the point where anyone in > one of the wgs could spew a paper on the matter in a couple of minutes. > Rule #1 about Unicode: If you think you know Unicode, then you do not know enough about Unicode to make that determination. Corollary: If you think something in Unciode would be "easy to implement", you do not know enough about Unicode to make that determination. Implementing a Unicode-aware `to_lowercase` is not a trivial matter. The Unicode case conversion algorithm requires not just a large data table, but some very oddball computations, as well as merging sequences of characters (which itself suggests normalization). > I assume there were 1001 proposals to implement some string manipulation > functionality in the std, why hasn't it been done ? > If you really want people to take your position seriously, then you should be willing to do some research. All of the proposals are public information , so you don't have to "assume" anything. -- 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/25d8a3a1-1712-4bc1-9a3a-c7fd2b67b119%40isocpp.org. ------=_Part_2805_890549700.1498697262415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, June 28, 2017 at 6:48:56 PM UTC-4, george.h.= ...@gmail.com wrote:
I assume the biggest argument against more diverse string manipulatio= n functions would be that strings are a container and, as such, most common= string related algorithms can be implemented with the algorithms library.<= div>
I feel like the biggest hurdle by far when presenting C+= + to a new person is the fact that I have to come up with an excuse for why= the language doesn't have basic string manipulation that they'd ex= pect it to have and tell them the alternative is to either use boost (and t= hat opens up another can of worms) or write their own. I also bet that ther= e are a metric ton of bugs out there that come as a result of poorly implem= ented string processing functions (e.g. implementations of to lower case th= at aren't compatible with unicode). I feel like having something like:<= /div>

void std::to_lowercase(std::string& str);

void std::to_uppercase(std::string& str);

void std::string_replace(std::string& str, std::s= tring pattern, std::string replacement);

void std:= :trim_right(std::string& str, std::string pattern =3D " ");

void std::trim(std::string& str, std::strin= g pattern =3D " ");

void std::trim_l= eft(std::string& str, std::string pattern =3D " ");
=

bool std::string_contains(std::string& str, st= d::string str); //(arguably this isn't need when we have find, but I st= ill have to read the documentation to understand how to use find, in this c= ase the func signature is enough to understand how to use it)

Ignoring the question of how to implement them, these a= re not algorithms. As you have written them, there is no reason not to make= them member functions of `std::string`. They don't even work with `bas= ic_string`s of non-`char` types, let along something like `string_view` or = any other string container/range.

The whole point of STL algorithms = is that they are uncoupled from the container on which they operate.= Your "algorithms" are specific to the container. Those aren'= t algorithms; they're just namespace-scoped functions.

= .... There's probably a dozen more necessary algorithm I haven't tho= ught of. I think they would be all easy to implement, to the point where a= nyone in one of the wgs could spew a paper on the matter in a couple of min= utes.

Rule #1 about Unicode: If you think = you know Unicode, then you do not know enough about Unicode to make that de= termination.

Corollary: If you think something in Unciode would be &= quot;easy to implement", you do not know enough about Unicode to make = that determination.

Implementing a Unicode-aware `to_lowercase` is n= ot a trivial matter. The Unicode case conversion algorithm requires not jus= t a large data table, but some very oddball computations, as well as mergin= g sequences of characters (which itself suggests normalization).
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

I assume there were 1001 proposals to implement some string m= anipulation functionality in the std, why hasn't it been done ?

If you really want people to take your position s= eriously, then you should be willing to do some research. All of the proposals are pub= lic information, so you don't have to "assume" anything.<= br>

--
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/25d8a3a1-1712-4bc1-9a3a-c7fd2b67b119= %40isocpp.org.
------=_Part_2805_890549700.1498697262415-- ------=_Part_2804_553728615.1498697262415-- .