220 36855 <32bedcad-92df-4d63-98ed-8f05c558cab7@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Fri, 9 Feb 2018 14:00:16 -0800 (PST) Lines: 241 Approved: news@gmane.org Message-ID: <32bedcad-92df-4d63-98ed-8f05c558cab7@isocpp.org> References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> <1731062.NdW3nXAon1@tjmaciei-mobl1> <14112472.AvYaaQfdXc@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5504_678290328.1518213616784" X-Trace: blaine.gmane.org 1518213515 2832 195.159.176.226 (9 Feb 2018 21:58:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 21:58:35 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB4NT7DJQKGQERR7SPXQ@isocpp.org Fri Feb 09 22:58:31 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekGgP-0007rQ-Lq for gclcip-std-proposals@m.gmane.org; Fri, 09 Feb 2018 22:58:14 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id l14sf5585249uaa.17 for ; Fri, 09 Feb 2018 14:00:19 -0800 (PST) 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=MejfLg90+dn3x03hP3KxQjUjnPI90vMO/HZARxDT8a0=; b=YR0jsLehE01XZbnK9C3n+m9PQ2X2QuzTs9kfMWEZ3zVa3Yhm6/XgCyO84bQCdfrUF0 oEOFpeqXocQk8EbdbDZGLkS+NUwSAc3SIOQyH5ZlHRYggU7yqxHAzrR9kwWU7Iksh0NV umu0jtw0XXpK7PkkUBvn0hOMjzhatyntpNJZ/AvUFNKIJwOl3YDHJeBUUEBtZ58WYIKq KYHh7CyVIanIzJFwWa9bD2NzEV5IS+4nhbsrqA1prgA4KYyTCHbEEtUjtFEC9ZQbvmMK wiLEbflP9YL88rJg9eaZ6SqGoaZpy5ILaRmYRjnR3wnMoOcinSTy4TD7bK5Amd6RYrn9 tDww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=MejfLg90+dn3x03hP3KxQjUjnPI90vMO/HZARxDT8a0=; b=ZSeeg7G6N0BCiYXhZ/gYbee3w2Fg9VMh70/KKPDnWIbOhH3jY5dBXfAcd4C/LG5xZ6 aefN8kkAtWQ+gZl2LSAoAMIbS/hueqnAqh/WGuuvdBfH7DE1K1d0eNfuG3ZrS+r7EhsL XZBz2zwGWBp3h4yITnh7N30RbLWk3bsiEJkc1G1mODMgvQPj2bjH4i6UTIupuPSuNBaQ bkNtR/65lKed1MDKOyKHsN8ZWLJxHDwY4WlnAFq36jV0Oe/JcWo7ecwhsJhirkciybNk iMVShZ80+imNZMVkIEFzYggx04DM9TbmWASpk1XqMY93Nxna97wCez5iVcsNdFMjgUq5 +sZw== 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=MejfLg90+dn3x03hP3KxQjUjnPI90vMO/HZARxDT8a0=; b=OvZWi7I+JFuBUHqjtQGJRvvlf8aa398XRMzMa4Vcf/ofKe847B84G3dcN3nWK+yv2v Ea+FOUVSP68EN2wkiWJ4ykl4qZIpMLrdT+lSMiNvLlk+eeUw+irCsnZINkMp0FJ6MbtX zw97nuGpcDI3iIRfpYr2Yx0z//ZFve1bKB1Mq/kcFcwocwXwcvJLH+rHtsCYGm60qGl8 +YbDmIR6E44zE5M67dQuFIdjFZ6yOeCa3BZftu8JHCe9zjwtnRe2ckajL9mhbrC2jZlZ awYPEXw8niVO4jXDZ8ZFLnOnuOw8/oAwnJ3phSHsmMXQoI1IeF+LfwJCWqlD9hEMziDo LeMQ== X-Gm-Message-State: APf1xPDylIDWhUbrs/4C1BD+I0Nbg/yyD1nbNe8SBVjMy8NIJnp85Z+B lQ7C02cbtgJ/G0jNmemFX7Lv+w== X-Google-Smtp-Source: AH8x224g83MBM7pD6V25b1OcIiUkvySUaXnZ7w7C2AX/Na6x65F8yRp/KwGotHD1BLT7UtRF6VWE0A== X-Received: by 10.31.86.135 with SMTP id k129mr2017544vkb.45.1518213618990; Fri, 09 Feb 2018 14:00:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.178.134 with SMTP id b128ls4353285vkf.7.gmail; Fri, 09 Feb 2018 14:00:17 -0800 (PST) X-Received: by 10.31.180.205 with SMTP id d196mr376092vkf.10.1518213617219; Fri, 09 Feb 2018 14:00:17 -0800 (PST) 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:36855 Archived-At: ------=_Part_5504_678290328.1518213616784 Content-Type: multipart/alternative; boundary="----=_Part_5505_1961679114.1518213616785" ------=_Part_5505_1961679114.1518213616785 Content-Type: text/plain; charset="UTF-8" On Friday, February 9, 2018 at 8:51:31 AM UTC-5, Jake Arkinstall wrote: > > On 9 Feb 2018 08:24, "Thiago Macieira" > > wrote: > > On Friday, 9 February 2018 00:05:44 PST Richard Hodges wrote: > > It's a great idea. Naysayers talk of performance concerns as a result of > > virtual functions. These are irrelevant. > > > > Firstly, the cost of turning numeric values into strings far outweighs > the > > cost of a virtual call > > That depends on a lot. The cost of a virtual call could easily get to 5% > total > time of a conversion, which is non-negligible, if there's no memory > allocation > involved. > > > 5% during a debug stage is no big deal. I set the scene for a good reason: > not all code is production code. > So... you want to add a language feature that you know up-front ought not be used in production code? No, the committee should not spend time on things like that. Not when there are genuine deficiencies in the language that matter for actual production code. We shouldn't be making language features that "production code" should avoid. We should be making "production code" *easier to write*. My focus here is making C++ friendlier until performance is a goal. > Again, you start from the presumption that "performance" and "friendliness" are diametrically opposed. I see nothing about writing conversion functions that require "unfriendliness". Just because it isn't the iostreams garbage doesn't make it unfriendly; just *new*. There is absolutely no reason, that I can see, to treat early development > with the same fine-tooth comb as the final product. > Early development code often *becomes* code in the final product. I've seen it happen in many projects. You write something quick and dirty, with the expectation that you'll refactor it later or something. But you never get the chance to actually do so; there are too many actually important things to be getting on with. So the bad code sits there. > Second, fixing iostream to make it more efficient is a separate concern. > > More than likely, doing that means replacing it entirely, which in turn > means > this feature cannot depend on iostreams. It must be generic, if it exists > at > all. > > > That would be nice, but generic is a royal pain in the backside in this > circumstance. > Then make it *not* be "a royal pain in the backside." Put forth a design that doesn't have these pain points. Simply declaring that it won't work without investigating the possibilities is defeatist. *Especially* since we're now on the cusp of having compile-time string manipulation in the language. I know that's not enough to do what you're talking about, but the existence of such a thing means that the idea is not beyond the realm of possibility. > This is not something that can be written in the current language because > it requires interpetation of the strings. > There are three aspects to this proposal: 1) the parsing of a string literal into sections of the literal and object names, 2) the conversion of each object name into a string, and 3) the concatenation of those bits of strings into the final string. Obviously, steps 2 and 3 can be rather interrelated. > How on earth that is supposed to generalise to choices of fmt, string > conversion and concatenation, stringstreams, and whatever magical solution > we're waiting on to make string manipulation efficient, I have no idea, > especially in the general situation where the different approaches - e.g. > to_string and operator<< - are not equivalent. > That's the thing with proposals. If you're serious about it, you *find* ways to solve the problems. Your proposal's biggest problem is that it binds a rightfully-maligned library construct to a language construct, thereby *permanently* affixing it into people's code, to the point where said language construct will be avoided by people who actually care about performance. You even acknowledge that this is a problem by saying that it's not for "production code". Why should we add language features that production code should avoid? The other thing is that you don't have to generalize the solution to be able to work with any conversion system. The problem is not that you've picked a *particular* library solution. It's that you've picked a *bad* particular library solution. -- 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/32bedcad-92df-4d63-98ed-8f05c558cab7%40isocpp.org. ------=_Part_5505_1961679114.1518213616785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, February 9, 2018 at 8:51:31 AM UTC-5, Jake Arki= nstall wrote:
On 9 Feb 2018 08:24, "Thiago Mac= ieira" <thi...@macieira.org> wrote:
On Friday, 9 February 2018 00:05:44 PST Richard Hodges wrote:
> It's a great idea. Naysayers talk of performance concerns as a res= ult of
> virtual functions. These are irrelevant.
>
> Firstly, the cost of turning numeric values into strings far outweighs= the
> cost of a virtual call

That depends on a lot. The cost of a virtual call could easily get to= 5% total
time of a conversion, which is non-negligible, if there's no memory all= ocation
involved.

5% during a debug stage is no big deal. I set the scene for = a good reason: not all code is production code.
So... you want to add a language feature that you know up-front ought= not be used in production code? No, the committee should not spend time on= things like that. Not when there are genuine deficiencies in the language = that matter for actual production code.

We shouldn't be making l= anguage features that "production code" should avoid. We should b= e making "production code" easier to write.

<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
My focus here is making C++ friendlier until performance is a goal.

Again, you start from the presumption that &= quot;performance" and "friendliness" are diametrically oppos= ed. I see nothing about writing conversion functions that require "unf= riendliness". Just because it isn't the iostreams garbage doesn= 9;t make it unfriendly; just new.

There is absolu= tely no reason, that I can see, to treat early development with the same fi= ne-tooth comb as the final product.

Early = development code often becomes code in the final product. I've s= een it happen in many projects. You write something quick and dirty, with t= he expectation that you'll refactor it later or something. But you neve= r get the chance to actually do so; there are too many actually important t= hings to be getting on with. So the bad code sits there.

> Second, fixing iostream to make it more efficient is a separate concer= n.

More than likely, doing that means replacing it entirely, which in tu= rn means
this feature cannot depend on iostreams. It must be generic, if it exists a= t
all.

That would be nice, but generic is a royal pain in the backside in th= is circumstance.

Then make it not b= e "a royal pain in the backside." Put forth a design that doesn&#= 39;t have these pain points.

Simply declaring that it won't work= without investigating the possibilities is defeatist. Especially si= nce we're now on the cusp of having compile-time string manipulation in= the language. I know that's not enough to do what you're talking a= bout, but the existence of such a thing means that the idea is not beyond t= he realm of possibility.
=C2=A0
This is not something that ca= n be written in the current language because it requires interpetation of t= he strings.

There are three aspects to thi= s proposal: 1) the parsing of a string literal into sections of the literal= and object names, 2) the conversion of each object name into a string, and= 3) the concatenation of those bits of strings into the final string. Obvio= usly, steps 2 and 3 can be rather interrelated.
=C2=A0
How on= earth that is supposed to generalise to choices of fmt, string conversion = and concatenation, stringstreams, and whatever magical solution we're w= aiting on to make string manipulation efficient, I have no idea, especially= in the general situation where the different approaches - e.g. to_string a= nd operator<< - are not equivalent.

= That's the thing with proposals. If you're serious about it, you find ways to solve the problems.

Your proposal's biggest pr= oblem is that it binds a rightfully-maligned library construct to a languag= e construct, thereby permanently affixing it into people's code,= to the point where said language construct will be avoided by people who a= ctually care about performance. You even acknowledge that this is a problem= by saying that it's not for "production code". Why should we= add language features that production code should avoid?

The other = thing is that you don't have to generalize the solution to be able to w= ork with any conversion system. The problem is not that you've picked a= particular library solution. It's that you've picked a b= ad particular library solution.

--
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/32bedcad-92df-4d63-98ed-8f05c558cab7= %40isocpp.org.
------=_Part_5505_1961679114.1518213616785-- ------=_Part_5504_678290328.1518213616784-- .