220 33093 <7ae413bd-2f04-4cd7-842b-bf47b0069b35@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: zamazan4ik@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why are there no standardized string manipulation algorithms ? Date: Mon, 3 Jul 2017 21:09:47 -0700 (PDT) Lines: 180 Approved: news@gmane.org Message-ID: <7ae413bd-2f04-4cd7-842b-bf47b0069b35@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_2185_1579200694.1499141387377" X-Trace: blaine.gmane.org 1499141390 4975 195.159.176.226 (4 Jul 2017 04:09:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2017 04:09:50 +0000 (UTC) Cc: george.h.personal@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGLZGV44EEBBDFK5TFAKGQE7IGA7HI@isocpp.org Tue Jul 04 06:09:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSF9j-00013p-PG for gclcip-std-proposals@m.gmane.org; Tue, 04 Jul 2017 06:09:43 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id f65sf8189524vkh.8 for ; Mon, 03 Jul 2017 21:09:49 -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=dHuKx35BtplLIXJnF540M6kBDQlKw+iILy9knspvGM8=; b=Zq+G8awqvIsfszfzfHu3Hr4zFLUHqcaeQPMoi3J93sekjOH5kXjTnKr1rfUA/dDFQT slRnzLCKsHTJKXI3KukV5b46lvhVAK2/KzX7ZZUulALoIcUXgD5jwOKtibPKlUmTuke0 h+6Z/TqqGinX2VWX0j9EBAvy6gCfZUUZm8l+9lkhyIzqe5ZQTsH3723071y+S7KyHGr3 QPfVNPHyBLWfyfPhw9KnrNznvzgC8F8OjTSweEzpTMenelsrQ6aanHhhMxjIDa1FdRlF R0bLPaBSubW9WKTbaIwfnKsCFxyd85yKCR9G6uC+8908EvBKElVYKz6fVfMkxiolHpRG E7Ag== 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=dHuKx35BtplLIXJnF540M6kBDQlKw+iILy9knspvGM8=; b=ac+ylu2TjSXf+Mx0bvXTmYvwx09OQohcuXd9GLy2+tE1BaL7XXaUSNhQSJGfU0++TE JAq1iEYEXJaiK/SutEJB+SQZFa4gZqp9kcyVcpg8vGE5bYxFeg4CS/FhiMk9BSd4qBGy jn82eKcxOFHDNYkZJ/q9aHJYDsP774L3EwCtpoJfQ68UtVXIydMdzSDefDS5FHU+HAfO OT79IyO+mVRE9bagbjb/xZmDwEH8BHpukrgLvK3G4KuuFvjG1Dqt9TdmWWP/cyTJsRqf /bkLiokX/63uZ+Zsamg89UV7MMNzRauMqok8GC4WGb1f6niJsES7NkIHC32qHzWs73ZK fCww== 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=dHuKx35BtplLIXJnF540M6kBDQlKw+iILy9knspvGM8=; b=TJHXFkvnMLxqOSmiqZqBYDcj2gC8EBt43sPQymB+4r+iwCaILbc9pA03AZZfCb4mup fKWwz0+Ls+nnPjs61p3zn7j2gzMD+kCOfY7/E1KoHsvO2hrxliOLqUxFqK9Rr/Dt8IXm x0+eprWotN1Rye1llpLtYvVHgtuYxHno/F5N6EpIfKUk3yip97vMysVwTvg5hBDA9BTO q9kEZJtXDOIEmt2HdPD7YmYKK0YjJcHrrESZbnQ9eYC8i5ulE/flzMy9vhG8H3OEG/KM VpsEAYJ3V8NTwhz6MFx8JAG0uisItrpB3fnCOuJxgCvo732rJUc5K6jRn8ZVTxvKOulp s6dQ== X-Gm-Message-State: AKS2vOxwZ+jd/RM/s3dhOuD43RevY7lahwFw4EqTg1z/GFZLEROUrv5A YTCQtvrEzdYNi19F X-Received: by 10.176.18.107 with SMTP id s43mr22838434uac.41.1499141389066; Mon, 03 Jul 2017 21:09:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.122.208 with SMTP id a199ls230998itc.5.gmail; Mon, 03 Jul 2017 21:09:48 -0700 (PDT) X-Received: by 10.36.125.65 with SMTP id b62mr948052itc.5.1499141387962; Mon, 03 Jul 2017 21:09:47 -0700 (PDT) In-Reply-To: <02cf02f4-df2e-4eb0-adcf-a7d167cd7e56@isocpp.org> X-Original-Sender: zamazan4ik@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:33093 Archived-At: ------=_Part_2185_1579200694.1499141387377 Content-Type: multipart/alternative; boundary="----=_Part_2186_1047685316.1499141387377" ------=_Part_2186_1047685316.1499141387377 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, it's well-known problem in C++. There are different problems: 1) Unicode problem (You read about it above) 2) STL is too conservative for new algorithms (i don't like it) 3) I think these functions shouldn't be methods inside std::string. It=20 should be free function + Unified call syntax. Because if i want to=20 implement my own ownNames::string, i want to use it simply. 4) Try to use Boost.StringAlgo - in this library you will find a lot of=20 algorithms for working with strings. =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 29 =D0=B8=D1=8E=D0=BD=D1=8F 201= 7 =D0=B3., 1:48:56 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0= =D1=82=D0=B5=D0=BB=D1=8C george.h...@gmail.com=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > I assume the biggest argument against more diverse string manipulation=20 > functions would be that strings are a container and, as such, most common= =20 > 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= =20 > is the fact that I have to come up with an excuse for why the language=20 > doesn't have basic string manipulation that they'd expect it to have and= =20 > tell them the alternative is to either use boost (and that opens up anoth= er=20 > can of worms) or write their own. I also bet that there are a metric ton = of=20 > bugs out there that come as a result of poorly implemented string=20 > processing functions (e.g. implementations of to lower case that aren't= =20 > 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,=20 > std::string replacement); > > void std::trim_right(std::string& str, std::string pattern =3D " "); > > void std::trim(std::string& str, std::string pattern =3D " "); > > void std::trim_left(std::string& str, std::string pattern =3D " "); > > bool std::string_contains(std::string& str, std::string str); //(arguably= =20 > this isn't need when we have find, but I still have to read the=20 > documentation to understand how to use find, in this case the func=20 > signature is enough to understand how to use it) > > ... There's probably a dozen more necessary algorithm I haven't thought= =20 > of. I think they would be all easy to implement, to the point where anyon= e=20 > in one of the wgs could spew a paper on the matter in a couple of minutes= ..=20 > The boost library already has some of these algorithms (though some are= =20 > surprisingly slow), so implementation could even be more or less copied= =20 > from there. > > Functions like std::min and std::max exist, and they are quite basic, so = I=20 > see no point in not having string manipulation functions just because the= y=20 > are simple in implementation. As for them being less generic than using= =20 > std::algorithm... that is true, but so is using std::string instead of=20 > using std::vector, in the end I think dropping some=20 > esoteric purity in design principle to make the language way more beginne= r=20 > friendly and avoid an insane amount of code duplication would be for the= =20 > greater good. > > That being my view on the matter, my questions is, why is this view wrong= =20 > ? I assume there were 1001 proposals to implement some string manipulatio= n=20 > functionality in the std, why hasn't it been done ? > --=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/7ae413bd-2f04-4cd7-842b-bf47b0069b35%40isocpp.or= g. ------=_Part_2186_1047685316.1499141387377 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, it's well-known problem in C++. There are differ= ent problems:
1) Unicode problem (You read about it above)
2) STL is= too conservative for new algorithms (i don't like it)
3) I t= hink these functions shouldn't be methods inside std::string. It should= be free function + Unified call syntax. Because if i want to implement my = own ownNames::string, i want to use it simply.
4) Try to use Boos= t.StringAlgo - in this library you will find a lot of algorithms for workin= g with strings.

=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 29 =D0= =B8=D1=8E=D0=BD=D1=8F 2017 =D0=B3., 1:48:56 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C= =D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C george.h...@gmail.com =D0= =BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
I assume the biggest argument against more diver= se 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 f= ar when presenting C++ to a new person is the fact that I have to come up w= ith an excuse for why the language doesn't have basic string manipulati= on that they'd expect it to have and tell them the alternative is to ei= ther 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 re= sult of poorly implemented string processing functions (e.g. implementation= s of to lower case that aren't compatible with unicode). I feel like ha= ving something like:

void std::to_lowercase(std::s= tring& str);

void std::to_uppercase(std::strin= g& str);

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

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

=
void std::trim_left(std::string& str, std::string pattern =3D &quo= t; ");

bool std::string_contains(std::string& str, std::string str); //(arguably this isn't need when w= e have find, but I still have to read the documentation to understand how t= o use find, in this case the func signature is enough to understand how to = use it)

... There's probably a dozen more nece= ssary 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. The boost library already has some of= these algorithms (though some are surprisingly slow), so implementation co= uld even be more or less copied from there.

Functi= ons like std::min and std::max exist, and they are quite basic, so I see no= point in not having string manipulation functions just because they are si= mple in implementation. As for them being less generic than using std::algo= rithm... that is true, but so is using std::string instead of using std::ve= ctor<rune_sized_type>, in the end I think dropping some esoteric puri= ty in design principle to make the language way more beginner friendly and = avoid an insane amount of code duplication would be for the greater good.

That being my view on the matter, my questions is, = why is this view wrong ? I assume there were 1001 proposals to implement so= me string manipulation functionality in the std, why hasn't it been don= e ?

--
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/7ae413bd-2f04-4cd7-842b-bf47b0069b35= %40isocpp.org.
------=_Part_2186_1047685316.1499141387377-- ------=_Part_2185_1579200694.1499141387377-- .