220 14853 <1b00c799-b47e-48b7-8717-9953b1845cca@isocpp.org> article Path: news.gmane.org!not-for-mail From: squelart@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Variable declarations inside test before block Date: Wed, 3 Dec 2014 23:09:37 -0800 (PST) Lines: 300 Approved: news@gmane.org Message-ID: <1b00c799-b47e-48b7-8717-9953b1845cca@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_410_78606994.1417676977070" X-Trace: ger.gmane.org 1417676987 17597 80.91.229.3 (4 Dec 2014 07:09:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2014 07:09:47 +0000 (UTC) Cc: squelart@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRYZZWM2ENBBM4RQCSAKGQEMHN6O7Y@isocpp.org Thu Dec 04 08:09:40 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XwQXk-00021G-9b for gclcip-std-proposals@m.gmane.org; Thu, 04 Dec 2014 08:09:40 +0100 Original-Received: by mail-qc0-f200.google.com with SMTP id r5sf37959905qcx.11 for ; Wed, 03 Dec 2014 23:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=WHUdixqd+DUJWq7HgKmOXvr8LfrojrEgULaMthS39oM=; b=vCKA4UnTsgp0T+cT4yfpYO1ys3vKP7oLDSSJSOOEYqITpi+Xho/GQ8Xp6gfcX+W+1M 1ccMaEwrsXLSfXSsY2ibvz3meqHZK1QAqli0EP23iEzkL7cCcAOJD53+D/hUWtvkdcqh a01hpvS9a/pJgVWU4Gosh7T7PMgOitmy1QE2433S9U6STNeG40TNXOMaMlPVUstvwQ5W 70Rdq3j3/PF/6l+DY7DuJWPYdqRHY/UHke+JVk9/T2/NxYXyx6T25+KkhYgkwAqsD3d5 LsTGtIqPhZSg5Q+W6yRx78nXoJtDgoSNWDq/Ywna65GHX1gfo/eAR+RuJf8zJWiuk4M/ Lv5g== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=WHUdixqd+DUJWq7HgKmOXvr8LfrojrEgULaMthS39oM=; b=EgiyEtZwdI4OGnyqUTZDtvkPtyryPHlllYLNWkucrtv4DTEkHh86C+Wy1YBxndzGSy qnMgZAV7Ile73uotUSFGDS0K5uXnXk+VtHVlQwFFNBqqVB9NclQcE/CWifpDuyAVHIUQ RJjyhsZPs3x2j+SpUJNyavLc1DEdzusm1gWvM5sjIwFTaYK/ISYET2umtUVFhe2eJlpN mvjMcrf/Mvbjp5CVMFuoqijZGGfgQtc1pZ/1JocTJt6dokeX2ORn+WLO4tFeDwuX0V6x SxTsR944fEXoxNAwwlvYEbqf0vJz6yLi0wr/spt+NSxwxp7XqdGFcO9UjSxsGkyhwmEA ikaQ== X-Gm-Message-State: ALoCoQmFmBXo8YtJkTdaCGRt/s3KHwamQ6MjbF6f5/wC58bkOM7J5Keki+WEY83iIcw46JG72ycl X-Received: by 10.236.1.201 with SMTP id 49mr8305823yhd.50.1417676979726; Wed, 03 Dec 2014 23:09:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.93.41 with SMTP id cr9ls807562igb.40.gmail; Wed, 03 Dec 2014 23:09:38 -0800 (PST) X-Received: by 10.51.17.104 with SMTP id gd8mr913219igd.11.1417676978883; Wed, 03 Dec 2014 23:09:38 -0800 (PST) In-Reply-To: X-Original-Sender: squelart@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:14853 Archived-At: ------=_Part_410_78606994.1417676977070 Content-Type: multipart/alternative; boundary="----=_Part_411_445305253.1417676977070" ------=_Part_411_445305253.1417676977070 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, December 3, 2014 7:37:24 PM UTC+11, Andrzej Krzemie=C5=84ski = wrote: > > W dniu =C5=9Broda, 3 grudnia 2014 05:21:27 UTC+1 u=C5=BCytkownik sque...@= gmail.com=20 > napisa=C5=82: >> >> (First time here, please let me know if I'm doing anything wrong!) >> >> Just a quick idea I couldn't find elsewhere with a quick search, I was= =20 >> wondering if it had already been proposed and/or rejected: >> >> Would it be possible and useful to allow variable declarations inside a= =20 >> test preceding a block, and make these variables visible inside the=20 >> remainder of the test and the block? >> (The "remainder of the test" part might be going too far?) >> The goal is to avoid polluting a block with variables that are really=20 >> only needed inside an inner block. >> >> E.g.: >> if ((auto total < (auto max =3D getMax()) - (auto buffer =3D max / 3)) >= 1) { >> // 'total', 'max' and 'buffer' are visible in this block and=20 >> destructed at the end. >> } >> >> while (nullptr !=3D (void* buffer =3D malloc(8))) { foo(buffer); } >> >> for (int i =3D 0; i < (int end =3D 10); ++i) { cout << end - i; } >> >> switch (char c =3D getchar()) { case '\0': break; default: cout << c; } >> >> auto f =3D (P* p =3D maybeP()) ? p->foo() : 0; // Too far again? >> >> Any pointers/suggestions/criticisms welcome. >> I'd be happy to work on it further if there's any interest. >> > =20 > Note that some of the above constructs are already valid in C++. > > while (void* buffer =3D malloc(8)) // > foo(buffer); // valid C++ > > for (int i =3D 0, end =3D 10; i < end; ++i) // different than your exampl= e > { cout << end - i; } // but similar functionality > > switch (char c =3D getchar()) // valid C++ > {=20 > case '\0': break;=20 > default: cout << c; > } > > for (iter.init(); int* i =3D iter.next();) // valid C++ > use(*i); > > Your proposal offers only a bit more. The question is, whether the added= =20 > value counterweights the costs of standardization effort, complicating th= e=20 > language, more rules for programmers to learn, compiler updates, etc. My= =20 > personal answer (based on feelings and intuition only) is that it is not= =20 > worth it. > > Regards, > &rzej > Thanks for your help, I didn't know about some of these. Always learning! I knew about "while (void* p =3D ...)", but it means the variable can only = be=20 tested for "falsiness", you can't have a test that declares a variable and= =20 compares it to an arbitrary non-false value. But as you say, it's "only a bit more", so it's probably not worth the huge= =20 effort to change the language just for that... Cheers, Gerald --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_411_445305253.1417676977070 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, December 3, 2014 7:37:24 PM UTC+11, Andrzej = Krzemie=C5=84ski wrote:
W dniu =C5=9Broda, 3 grudnia 2014 05:21:27 UTC+1 u=C5=BCytkownik = sque...@gmail.com napisa=C5=82:
(First time here, please let me know if I'm doing anyth= ing wrong!)

Just a quick idea I couldn't find elsewhere with a quick= search, I was wondering if it had already been proposed and/or rejected:
Would it be possible and useful to allow variable declarations inside= a test preceding a block, and make these variables visible inside the rema= inder of the test and the block?
(The "remainder of the test" part might= be going too far?)
The goal is to avoid polluting a block with variable= s that are really only needed inside an inner block.

E.g.:
if ((auto total < (auto max =3D getMax()) - (auto buffer =3D max / 3)) > 1)= {
&= nbsp;   // 'total', 'max' and 'buffe= r' are visible in this block and destructed at the end.
}

while (nullptr !=3D (void* buffer =3D malloc(8))) { foo(buffer); }

for (int i =3D 0; i < (= int end =3D 10); ++i) { cout << end - i; }

= switch = (char c =3D getchar()= ) { case '\0'<= span style=3D"color:#660">: break; default: cout << c; }

auto f =3D (P* p =3D maybeP()) ? p->foo() : 0<= /span>; // Too far again?

Any pointers/suggestions/critici= sms welcome.
I'd be happy to work on it further if there's any interest.=
 
Note that some of the above co= nstructs are already valid in C++.

=
<= div>while (void* buffer =3D malloc<= /span>(8)) //
  foo<= /span>(buffer<= /span>);  = ;                 // valid C++

for = (int i =3D 0, end =3D 10; i < end= ; ++i)<= span style=3D"color:#000"> // different t= han your example
{ cout << end - i; }           =          // but = similar functionality

switch (char c =3D getchar())  // valid C+= +
{<= /span>
cas= e '\0'<= /span>: break;=
default: cout << = c;
<= /span>}
for (iter.init(); int* i =3D iter.next();) // valid C++=
  use= (*i);

Your prop= osal offers only a bit more. The question is, whether the added value count= erweights the costs of standardization effort, complicating the language, m= ore rules for programmers to learn, compiler updates, etc. My personal answ= er (based on feelings and intuition only) is that it is not worth it.
Regards,
&rzej

Thanks for you= r help, I didn't know about some of these. Always learning!

I knew a= bout "while (void* p =3D ...)", but it means the variable can only be teste= d for "falsiness", you can't have a test that declares a variable and compa= res it to an arbitrary non-false value.

But as you say, it's "only a= bit more", so it's probably not worth the huge effort to change the langua= ge just for that...

Cheers,
Gerald

--

---
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_411_445305253.1417676977070-- ------=_Part_410_78606994.1417676977070-- .