220 40778 article Path: news.gmane.org!.POSTED!not-for-mail From: pasa@lib.hu Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: a string type for APIs Date: Fri, 26 Oct 2018 09:48:22 -0700 (PDT) Lines: 113 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_993_110826378.1540572502751" X-Trace: blaine.gmane.org 1540572382 13898 195.159.176.226 (26 Oct 2018 16:46:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 16:46:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDXOZDWV5QORBV4KZXPAKGQE22PSA6Q@isocpp.org Fri Oct 26 18:46:18 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG5FZ-0003Wm-PK for gclcip-std-proposals@m.gmane.org; Fri, 26 Oct 2018 18:46:17 +0200 Original-Received: by mail-yw1-f69.google.com with SMTP id d6-v6sf1006271ywa.7 for ; Fri, 26 Oct 2018 09:48:28 -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: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=xzqQgHSnbk/2mTV28u8g+FHvhg0WBKuKD5nB+3iJaZg=; b=wI8FlJTchynQIdfoOCkmp3Y9MPdntALwMgjX3xKroBB96SaSlGk3CLxNgKEC+lHq3d 7hKbfmR5a3t5M8tKtXHZFz9W0dY1NaHCaiGPNUMU8dXTwH69nfSEe9aMTwdtA/29HaKV GsVOzo8sdJYrboRI0NF0NsZBG5rBuf9F0LF7N8Eh8T9CAKeFa1vZOhYg5EINTcIAEZXQ Pv5Bk/kYT2BCdiP/bWs/iH4qA4Rvc+rnGR0vNc96ts5IQLUeHgSl5ZYt9cNs0uLHNlx8 pBR2GLRPpIv/RYqufebTsicbZ93Jd+J07Fhc8JAjJ4cgzY2C9hI3NlXkGrezIn0EEeio e82A== 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: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=xzqQgHSnbk/2mTV28u8g+FHvhg0WBKuKD5nB+3iJaZg=; b=DFCDv5IxHVgRy5XjiG1y1HvpLlPmILlgYOv+MNlqsjJOE6SGA9yL19az4/n35IbWDd hJ8D2rHMfJwuhHga895BB7fEigUr/aevZd/Zz2fx5PbggcfPYGpZdUFHzlTYAFBkhnmc H9w2J4xh3++BnnQNNf1IOnkkojgh2jXLslnLVhYV5ha5XmvubMDknAHTV2bafAMpUxw9 khvZ0I6Jl8XT4lv2sIBYI8pAMEh9aCMXifnCXo2ZLxjRDpOtrvZHVzzir0leDTzFy6TP 4gIhC55/8nUbSoCUm8htDgTWizLIafJRIPB2OOyhisb67yGeOc1iqq+Hvh7qyHNUBsj3 P+SA== X-Gm-Message-State: AGRZ1gJJXKVATlZS5ouvy8wkZQ/ce85Qk5ApL0wcvyprj9LLZDMYx/u2 JNbKK5tvIqcA51BTl8oiK30y3Q== X-Google-Smtp-Source: AJdET5fGFGbKXzQPwTiiTt7AaVURcgRstb8EMbUeezqzfPAQ0wg7dJeqz55nhRRpwcwPHVfXLD32CQ== X-Received: by 2002:a81:5785:: with SMTP id l127-v6mr2628211ywb.26.1540572507955; Fri, 26 Oct 2018 09:48:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3d45:: with SMTP id k66-v6ls1294843ywa.11.gmail; Fri, 26 Oct 2018 09:48:23 -0700 (PDT) X-Received: by 2002:a81:13d4:: with SMTP id 203-v6mr43542ywt.5.1540572503532; Fri, 26 Oct 2018 09:48:23 -0700 (PDT) In-Reply-To: X-Original-Sender: pasa@lib.hu 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:40778 Archived-At: ------=_Part_993_110826378.1540572502751 Content-Type: multipart/alternative; boundary="----=_Part_994_1398337227.1540572502751" ------=_Part_994_1398337227.1540572502751 Content-Type: text/plain; charset="UTF-8" By a pint I would say "we already have one abomination for a standard string, do we really need more of them?" but let's skip over that, As I can see worse things than to work with a suboptimal string type in an application: that is to work with *multiple* string types. It's problematic even in a library, say the standard. Did you read early criticisms, like yey, C++ lib now have an actual string -- too bad the said lib is not aware of it at all. fopen and a zillion other parts talk char const*. Some of the more recent parts (filesystem?) might be ahead. Now suppose there was a general improvement and the library learned to talk std::string. And your version gets in. Now all those functions should learn std::astring too, maybe with all combinations. Yeah, there are cute methods to deal with the mess (see Matthew Wilson's shims, veneers and other adapters) but wise people just want to avoid the mess in the first place. And that route is still a huge task. I think that is one of the main reasons we're still stuck with the one std::string despite it was not exactly liked from the boot and capital mistakes discovered (not limited to originally aiming COW that was forbidden). IMHO if you presented a perfect magical thing that combined all the benefits of all known designs (and we had many even pre-standard), it would still be an uphill battle to get in. One that could be won with 'you can just replace your std::string usage'. And yours is not really impressive, and whoever wanted an immutable string, instead of picking up one of the actually good full-featured ones just wrote it, and is using it for decades. While the compilation time argument is very artificial, your diff stands up only in writing "hello world" -- in any realistic application you start with including half of STL and a ton of platform/framework headers. Plenty of those probably precompiled. So there the difference will just disappear. Or turn the other way, considering the chances already got included just because some component supported it. Meanwhile I fully support the suggestion others made: publish your string as standalone library (maybe in boost, but outside is okay too). For those who find it useful it will not lack the std:: prefix. -- 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/bcf21167-2686-4647-80ca-ae92eeaf6115%40isocpp.org. ------=_Part_994_1398337227.1540572502751 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By a pint I would say "we already have one abomi= nation for a standard string, do we really need more of them?" but let= 's skip over that, As I can see worse things than to work with a subopt= imal string type in an application: that is to work with *multiple* string = types.

It's problematic even in a library, say= the standard. Did you read early criticisms, like yey, C++ lib now have an= actual string -- too bad the said lib is not aware of it at all. fopen and= a zillion other parts talk char const*. Some of the more recent parts (fil= esystem?) might be ahead.=C2=A0 Now suppose there was a general improvement= and the library learned to talk std::string. And your version gets in. Now= all those functions should learn std::astring too, maybe with all combinat= ions.

Yeah, there are cute methods to deal with th= e mess (see Matthew Wilson's shims, veneers and other adapters) but wis= e people just want to avoid the mess in the first place. And that route is = still a huge task.

I think that is one of the main= reasons we're still stuck with the one std::string despite it was not = exactly liked from the boot and capital mistakes discovered (not limited to= originally aiming COW that was forbidden).=C2=A0

=
IMHO if you presented a perfect magical thing that combined all the be= nefits of all known designs (and we had many even pre-standard), it would s= till be an uphill battle to get in. One that could be won with 'you can= just replace your std::string usage'.

And you= rs is not really impressive, and whoever wanted an immutable string, instea= d of picking up one of the actually good full-featured ones just wrote it, = and is using it for decades.=C2=A0=C2=A0 While the compilation time argumen= t is very artificial, your diff stands up only in writing "hello world= " -- in any realistic application you start with including half of STL= and a ton of platform/framework headers. Plenty of those probably precompi= led. So there the difference will just disappear.=C2=A0 Or turn the other w= ay, considering the chances <string> already got included just becaus= e some component supported it.

Meanwhile I fully suppor= t the suggestion others made: publish your string as standalone library (ma= ybe in boost, but outside is okay too). For those who find it useful it wil= l not lack the std:: prefix.

--
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/bcf21167-2686-4647-80ca-ae92eeaf6115= %40isocpp.org.
------=_Part_994_1398337227.1540572502751-- ------=_Part_993_110826378.1540572502751-- .