220 33001 <02cf02f4-df2e-4eb0-adcf-a7d167cd7e56@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: george.h.personal@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Why are there no standardized string manipulation algorithms ? Date: Wed, 28 Jun 2017 15:48:55 -0700 (PDT) Lines: 128 Approved: news@gmane.org Message-ID: <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_1739_304261109.1498690135990" X-Trace: blaine.gmane.org 1498690140 8253 195.159.176.226 (28 Jun 2017 22:49:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Jun 2017 22:49:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDWY7A6E54DBBWHE2DFAKGQEAMYGB4Y@isocpp.org Thu Jun 29 00:48:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQLlU-0001iZ-NM for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 00:48:52 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id r36sf51503854ioi.6 for ; Wed, 28 Jun 2017 15:48:58 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=D7nC0mJcak8KoiuE3vEugIDiEE6aMmH/KhS6hOCTDWQ=; b=J+2T9MwnN3nI6ajF3NTiGcoeUnzNfetbdZRUnqiY6O+4iXc9+8vNnjjN0t9Blx0bB0 UDjVvfh/OtUMsayMOkbV1ofJQ2Y3DwoEJg+4y/YbJp9amoqp6b7AZCiwP+tgxGcfwXIO PAMUk01zlWiPu+sZmhi2DYxcbtYSQ+KAa4z80ZX1J7f6seG5SSUa4N5ntP1lHxj9BwPz MnCnuJtH3OPOWVWfqw9anHWjK7ciFIq0WqDeuwp7dbICM1tl60rxFLWbLMDaba9ZFRK3 xRC/ZIDHJVumaM6UwIQI2pAI0Fut6mnx1RPcvohch8wEUR1SA7d8UuqsCX6ED5Ibf3WA rEVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=D7nC0mJcak8KoiuE3vEugIDiEE6aMmH/KhS6hOCTDWQ=; b=O3vZFDgkeAyvZZTOwHL4kp1YTfol4mLbKtVNdd+yX93r+TpSnrwlqz+osRM7rS7/+z kHucoytdDPx8tR6S/ZZr39QCJOOcErWhRz9/7cUftyInYWp1se/rd1CEySEI2KID5awg rsp25l25/V5Yl0OZWnvHhMeOIDuO4hbvM+f/S/ycgTErsdz5obhyKkTTxTGrkKsOOmoi eMjvZo38iIg9GqUZGk218neSdd9SwlYyrtc0IrqHO3dv9hbCLY/QD+Jz6glqu6wIIAh7 f1/Gl8iRcIOz883ZfP393D7qiGg0jwZicyQ9oyw00zNFA5Injb1kCv7ri04CEhUJUtxi YCBw== 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:message-id: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=D7nC0mJcak8KoiuE3vEugIDiEE6aMmH/KhS6hOCTDWQ=; b=UeSildYYp+fm2s5mtcfC6tb9HJO333kz/wBNW46SvH1WB4ZRVv4IJ6zcpb6l0q/9co FCpAxT1OvmIULVOHsFQ2wb5SQaQaNS9DLq3q5iGIKLjxwU9KXyxG+fFaeisz00Kq8WXA m+FsgFY3uWFgOrVhSd9mCe/Qi+M0JeZOl7vwHZTLzSnnelmFMdJDZjPWwOCQ0A+GG5eM B34DDVX7dUJEqRozrmC7bRJL9wDpoECWZ8j8AbM7sb1pWnZ3Gigy3Medz2wk1s+MR1wt //cmW06XhO1qajcTS+xErD+jUvPuFLzTFySIOYscKrQI+1UAcSPAjhNOUMZ5UIDOI/gV BV4A== X-Gm-Message-State: AKS2vOy8Kj1b+P07LF2Wkgst/SaZ4PzQiL2rJEiovMSXvXF8xgaPtBqe 66VpdFBVM2ld8tPQ X-Received: by 10.36.89.16 with SMTP id p16mr5524521itb.10.1498690137899; Wed, 28 Jun 2017 15:48:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.46.156 with SMTP id u28ls6428819iou.4.gmail; Wed, 28 Jun 2017 15:48:56 -0700 (PDT) X-Received: by 10.36.26.85 with SMTP id 82mr155999iti.6.1498690136556; Wed, 28 Jun 2017 15:48:56 -0700 (PDT) X-Original-Sender: george.h.personal@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:33001 Archived-At: ------=_Part_1739_304261109.1498690135990 Content-Type: multipart/alternative; boundary="----=_Part_1740_1679743719.1498690135990" ------=_Part_1740_1679743719.1498690135990 Content-Type: text/plain; charset="UTF-8" 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) .... 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. The boost library already has some of these algorithms (though some are surprisingly slow), so implementation could even be more or less copied from there. Functions 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 simple in implementation. As for them being less generic than using std::algorithm... that is true, but so is using std::string instead of using std::vector, in the end I think dropping some esoteric purity 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 some string manipulation functionality in the std, why hasn't it been done ? -- 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/02cf02f4-df2e-4eb0-adcf-a7d167cd7e56%40isocpp.org. ------=_Part_1740_1679743719.1498690135990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 algorithm= s library.

I feel like the biggest hurdle by far when pr= esenting C++ to a new person is the fact that I have to come up with an exc= use for why the language doesn't have basic string manipulation that th= ey'd expect it to have and tell them the alternative is to either use b= oost (and that opens up another can of worms) or write their own. I also be= t that there are a metric ton of bugs out there that come as a result of po= orly implemented string processing functions (e.g. implementations of to lo= wer case that aren't compatible with unicode). I feel like having somet= hing 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);

voi= d std::trim_right(std::string& str, std::string pattern =3D " &quo= t;);

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, s= td::string str); //(arguably this isn't need when we have find, but I s= till 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)
... There's probably a dozen more necessary algorithm I ha= ven't thought of. I think they would be all easy to implement, to the p= oint where anyone in one of the wgs could spew a paper on the matter in a c= ouple of minutes. The boost library already has some of these algorithms (t= hough some are surprisingly slow), so implementation could even be more or = less copied from there.

Functions like std::min an= d std::max exist, and they are quite basic, so I see no point in not having= string manipulation functions just because they are simple in implementati= on. As for them being less generic than using std::algorithm... that is tru= e, but so is using std::string instead of using std::vector<rune_sized_t= ype>, in the end I think dropping some esoteric purity in design princip= le to make the language way more beginner friendly and avoid an insane amou= nt of code duplication would be for the greater good.

<= div>That being my view on the matter, my questions is, why is this view wro= ng ? I assume there were 1001 proposals to implement some string manipulati= on functionality in the std, why hasn't it been done ?

--
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/02cf02f4-df2e-4eb0-adcf-a7d167cd7e56= %40isocpp.org.
------=_Part_1740_1679743719.1498690135990-- ------=_Part_1739_304261109.1498690135990-- .