220 21272 <639fb5e3-6dc7-43b0-ae27-82e8762054c8@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vlad from Moscow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Overloading of the family of numeric conversion functions std::stoXXX Date: Sun, 4 Oct 2015 08:39:24 -0700 (PDT) Lines: 335 Approved: news@gmane.org Message-ID: <639fb5e3-6dc7-43b0-ae27-82e8762054c8@isocpp.org> References: <2071233.DJFaRXvRqy@tjmaciei-mobl4> <7a3293d7-e29f-4218-bb6e-e693b58ff0c9@isocpp.org> <12340581.HpIxkRuByo@tjmaciei-mobl4> <8232d2bf-4340-441f-919e-e5eca8b2ad22@isocpp.org> <3a87a6d9-d7cd-4620-aa9c-0ac8a1acc8f3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2570_1296458142.1443973164807" X-Trace: ger.gmane.org 1443973169 9630 80.91.229.3 (4 Oct 2015 15:39:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 15:39:29 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCXLLRHD7IDRBLUQYWYAKGQEURCD5GA@isocpp.org Sun Oct 04 17:39:29 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZilNo-0007wx-5D for gclcip-std-proposals@m.gmane.org; Sun, 04 Oct 2015 17:39:28 +0200 Original-Received: by oiev17 with SMTP id v17sf239142756oie.1 for ; Sun, 04 Oct 2015 08:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type: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=RvhFZSPTF601H/Db4cp0uXTixAnZPisklsE0lchESDM=; b=Clknr5phVuLBDpU2w2mynToPGXtPdQ29J5mSHYB1y+LlWXjbWmbX5gO4gcBO9QgZwt q8SUFLgPbPhNH84CUiCdcdX89/2kBy3nZJm7OGZy2A+8ToK+1GZnadt8WD5kVcDMxb+S Rv+3S+jSuuEUzMRMUMDD9EKZuQwK1IJpg1Kct0DeW3ieyls/DcvYS2awRvp3SZ3PLJEK 6oBuCjRS5sNjDWbbnsT/0/K9c90z9oiHQi7HFDFH3aZ6pcMYkm3FzQgmb7UU/H5jSLyM 1kP9jkivLXSBpib1AyiKxld364h4QqbkKbsZxvHADGSVmE3aHc2uLsexXcoO8mK8UCsQ jQsw== X-Gm-Message-State: ALoCoQlbNFpPCIIs0pb4jwqb+/IytbmCZV92CUX/kos3FTQTCmwEe58/WyHFKB3nRcB8SROAlBme X-Received: by 10.50.43.233 with SMTP id z9mr6937854igl.9.1443973166685; Sun, 04 Oct 2015 08:39:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.133.133 with SMTP id p5ls993143ioi.78.gmail; Sun, 04 Oct 2015 08:39:25 -0700 (PDT) X-Received: by 10.50.79.136 with SMTP id j8mr76860igx.16.1443973165855; Sun, 04 Oct 2015 08:39:25 -0700 (PDT) In-Reply-To: <3a87a6d9-d7cd-4620-aa9c-0ac8a1acc8f3@isocpp.org> X-Original-Sender: vlad.moscow@mail.ru 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:21272 Archived-At: ------=_Part_2570_1296458142.1443973164807 Content-Type: multipart/alternative; boundary="----=_Part_2571_1699344524.1443973164807" ------=_Part_2571_1699344524.1443973164807 Content-Type: text/plain; charset=UTF-8 On Sunday, October 4, 2015 at 5:18:53 PM UTC+3, Nicol Bolas wrote: > > On Sunday, October 4, 2015 at 7:06:51 AM UTC-4, Vlad from Moscow wrote: >> >> There is a very simple and efficient method to determine what approach is >> more intuitively clear. >> >> > Just give a corresponding assignment to a beginner and look how he will >> try to do it. >> > > Wait, you said "intuitively clear" at first. Then you switched to talking > about "beginners". > > Beginners are beginners precisely *because* they have no experience. And > experience is how you develop *intuition*, and thus how you know what is > "intuitively clear" and what is not. > > I'm an experienced C++ programmer, and the code you posted is *mud* to > me. It is by no reasonable definition of the word "clear". It most > certainly is not "intuitively clear". Oh, I can figure out what it's doing > by staring at it for a while. > > But it is trash code. You may argue that it's the kind of trash code that > a beginner would write, but that only proves my point: beginners don't know > what clear code looks like. > > You're using the wrong standard to evaluate whether code is clear or not. > > >> So if you ask a beginner to output all numbers in a string I assure you >> that his approach will look something like the following >> > > I contest your notion that this is what any beginner would write. Oh, this > is what *some* beginners would write, to be sure. But those beginners > would be beginners at *C programming*, not C++ programming. Even > pre-C++11 C++. > > Any beginner from one of Bjarne's intro classes would *never* write such > filth (they'd be using iterators). Any beginner who bothered to actually > look at the documentation of std::string would have found string search > functions and would use them. Any beginner who had been paying attention to > C++ at all would avoid such code. > > There is a difference between "beginner" and "ignoramus". The programmer > you cite seems to be the latter. And those are *not* programmers we > should cater to. > > We should not encourage abusive use of the API. We should not encourage > ignorance or sloth among programmers. We should not add library features > that only cater to C-in-C++-style programmers. > > Your suggestion helps nobody but them. > > Beginners can learn to properly use the API. Bjarne proves that every year > with his beginning programming classes. They can be trained to use > iterators, ranges, and so forth. We should make these features available, > not for advanced programmers, but for beginners too. > > Because beginners are the ones who will make the most mistakes. Just look > at all that code you posted. Few beginners would get that right the first > time. Or second. They'll waste hours trying to figure out where they went > wrong. > > Whereas this code is much easier to write and read, and has fewer points > for mistakes: > > std::string s = ...; > auto sv = std::string_view(s); > > while(true) > { > auto ix = sv.find_first_of("0123456789"); > if(ix == std::string::npos) break; > sv = sv.remove_prefix(ix); > > int advance; > auto value = stoi(sv, &advance); > sv = sv.remove_prefix(advance); > > std::cout << value << " "; > } > > Shorter code. Less places to screw up. This is what beginners *ought* to > be writing. Beginners can learn to do this if you actually teach them the > API. > > Your way assumes that beginners only know that strings are an array of > characters with a size. My way assumes that beginners know that strings are > objects with actual functions. Your way assumes ignorance and sloth; my way > does not. > > Your way leads *inevitably* to brittle code, difficult-to-modify code, > and bad *programmers*. My way encourages the use of robust code, > easy-to-modify code, and good programmers. > > So why should we do things your way? > Beginners select a straightforward approach. And even professional programmers when they encouter a new task first of all try to use those knoweledge they have that is they select a straightforward approach. There is no any need to envent new entities if you have already all to resolve a problem. New things are invented only in case when you can not resolve a problem. remove_prefix has nothing common with the problem because the task is not to remove something in a string. A string with numbers has nor prefix nor suffix and it shall be unchanged. So using remove_prefix is simply an invalid idiom for this task. The task is done simply as the code of a beginner that I showed does. At first you have to find the position of a number and then extract the number. That is all. To find a position is an immutable operation. To extract a number is also immutable operation. What are you going to remove?! Moreover you even do not see that your code does not make sense because all what you are doing is inventing new enity string_view just to write auto value = stoi(sv, &advance); instead of auto value = stoi( s, pos, &pos ); My congratulations!:) It is a great achievment in programming!:) -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_2571_1699344524.1443973164807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, October 4, 2015 at 5:18:53 PM UTC+3, Nicol Bolas wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin= g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;= border-left-style: solid;">
On Sunday, October 4, 2015 at = 7:06:51 AM UTC-4, Vlad from Moscow wrote:
= There is a very simple and efficient method to determine what approach is m= ore intuitively clear.
=C2=A0
Just give a corresponding assignment to a beginner and look how= =C2=A0 he will try to do it.=C2=A0

Wait, you sai= d "intuitively clear" at first. Then you switched to talking abou= t "beginners".

Beginners are beginners precisely becaus= e they have no experience. And experience is how you develop intuiti= on, and thus how you know what is "intuitively clear" and wha= t is not.

I'm an experienced C++ programmer, and the code you po= sted is mud to me. It is by no reasonable definition of the word &qu= ot;clear". It most certainly is not "intuitively clear". Oh,= I can figure out what it's doing by staring at it for a while.

= But it is trash code. You may argue that it's the kind of trash code th= at a beginner would write, but that only proves my point: beginners don'= ;t know what clear code looks like.

You're using the wrong stand= ard to evaluate whether code is clear or not.
=C2=A0
So if you=C2=A0ask a beginner to output all = numbers in a string I assure you that his approach will look something like= the following

I contest your notion that this i= s what any beginner would write. Oh, this is what some beginners wou= ld write, to be sure. But those beginners would be beginners at C progra= mming, not C++ programming. Even pre-C++11 C++.

Any beginner fro= m one of Bjarne's intro classes would never write such filth (th= ey'd be using iterators). Any beginner who bothered to actually look at= the documentation of std::string would have found string search functions = and would use them. Any beginner who had been paying attention to C++ at al= l would avoid such code.

There is a difference between "beginne= r" and "ignoramus". The programmer you cite seems to be the = latter. And those are not programmers we should cater to.

We = should not encourage abusive use of the API. We should not encourage ignora= nce or sloth among programmers. We should not add library features that onl= y cater to C-in-C++-style programmers.

Your suggestion helps nobody = but them.

Beginners can learn to properly use the API. Bjarne proves= that every year with his beginning programming classes. They can be traine= d to use iterators, ranges, and so forth. We should make these features ava= ilable, not for advanced programmers, but for beginners too.

Because= beginners are the ones who will make the most mistakes. Just look at all t= hat code you posted. Few beginners would get that right the first time. Or = second. They'll waste hours trying to figure out where they went wrong.=

Whereas this code is much easier to write and read, and has fewer p= oints for mistakes:

std::string s =3D ...;
auto sv =3D std::string_view(s);

while(true)
{
=C2=A0 auto ix =3D sv.find_first_of("0123456789"
=C2=A0 if(ix =3D=3D std::string::npos) break;=
=C2=A0 sv = =3D sv.remove_= prefix(ix);
=C2=A0 int advance;
=C2=A0 auto value =3D stoi(sv, &advance);<= br>=C2=A0 sv =3D sv.remove_prefix(advance);

=C2=A0 std::cout << value << " ";
}

Shorter code. Less places to screw up. This is what beg= inners ought to be writing. Beginners can learn to do this if you ac= tually teach them the API.

Your way assumes that beginners only know= that strings are an array of characters with a size. My way assumes that b= eginners know that strings are objects with actual functions. Your way assu= mes ignorance and sloth; my way does not.

Your way leads inevitab= ly to brittle code, difficult-to-modify code, and bad programmers. My way encourages the use of robust code, easy-to-modify code, and good = programmers.

So why should we do things your way?

Beginners select a straightforward approach. = And even professional programmers when they=C2=A0encouter a new task first = of all try to use those knoweledge they have that is they select a straight= forward approach.

There is no any need to envent n= ew entities if you have already all to resolve a problem. New things are in= vented only in=C2=A0case when you can not resolve a problem.
remove_prefix has nothing = common with the problem because the task is not to remove something in a st= ring. A string with numbers has nor prefix nor suffix and it shall be uncha= nged.

So using remove_prefix is simply an invalid idiom for this task.

The task is done simply as = the code of a beginner that I showed does.

At first you have to find the position of a number and t= hen extract the number.=C2=A0 That is all.

To find=C2=A0a position is an immutable operation. To ex= tract a number is also immutable operation.

What are you going to remove?!
=
Moreover you even do not see that your code doe= s not=C2=A0make sense because all what you are doing is inventing new enity= string_view just to write

<= /span>
=C2=A0 auto value =3D stoi(sv, &advance);=


instead of
<= font color=3D"#000000">
=C2=A0= auto value =3D stoi( s, pos, &pos );


My congratulations!:)=C2=A0 It is a great achievment in = programming!:)




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2571_1699344524.1443973164807-- ------=_Part_2570_1296458142.1443973164807-- .