Do ... while structure improvement

[c***@ncomputers.org]

Do ... while structure improvement
Sometimes the use of jumps such as: continue, break, goto, calls to a
function, etc. is necessary to avoid the execution of some instructions.

For example: A loop requires auxiliary variables, which change each cycle,
but after the last one, they must either remain unchanged or it is useless
to change them.

This is the case of the seed, warp and swap loops of this solution for the
n queens problem
<http://ncomputers.org/content/code.php?src=n-queens/n-queens.cpp>.

To avoid the use of jumps or tricks on some of these cases, we are
suggesting the below improvement to the *do ... while loop structure*.

*Examples: *Print arrays separating its elements
<http://ncomputers.org/content/code.php?src=examples/do%20while%201.cpp>

/* author: ncomputers.org */
int main(){
unsigned int loop1=0;
unsigned int loop2;
unsigned int result=0;
unsigned int auxiliary1=1,auxiliary2=2,auxiliary3=3;
while(loop1++<1000000000){
/*
* Allow initializers (extra improvement)
*/
do(loop2=0){
result+=auxiliary1;
result-=auxiliary2;
result*=auxiliary3;
}while(++loop2<10){
/*
* Statements that will happen after the execution of each cycle
* and only if there is a next cycle.
*/
auxiliary1+=auxiliary3;
auxiliary2*=auxiliary1;
auxiliary3-=auxiliary2;
}
}
return 0;
}

Best regards,

http://ncomputers.org
<http://ncomputers.org/content/code.php?src=suggestions/do%20while.cpp>

[Pablo Oliva]

So, IIUC:

do (*statement*)
{
// *A*
}
while (*condition*)
{
// *B*
}

will run statement before entering the loop, will perform A inconditionally
one time, will check condition, and if condition holds, it will run B and
then A, then check condition again, and so on?

It seems somewhat contrived. Moving *statement* before the loop seems
semantically equivalent. And having two different code blocks depending on
the same condition appears hard to read.

Also, are variables declared in block B visible in block A, or are they two
completely separated code blocks?

Post by c***@ncomputers.org
Do ... while structure improvement
Sometimes the use of jumps such as: continue, break, goto, calls to a
function, etc. is necessary to avoid the execution of some instructions.
For example: A loop requires auxiliary variables, which change each cycle,
but after the last one, they must either remain unchanged or it is useless
to change them.
This is the case of the seed, warp and swap loops of this solution for
the n queens problem
<http://ncomputers.org/content/code.php?src=n-queens/n-queens.cpp>.
To avoid the use of jumps or tricks on some of these cases, we are
suggesting the below improvement to the *do ... while loop structure*.
*Examples: *Print arrays separating its elements
<http://ncomputers.org/content/code.php?src=examples/do%20while%201.cpp>
/* author: ncomputers.org */
int main(){
unsigned int loop1=0;
unsigned int loop2;
unsigned int result=0;
unsigned int auxiliary1=1,auxiliary2=2,auxiliary3=3;
while(loop1++<1000000000){
/*
* Allow initializers (extra improvement)
*/
do(loop2=0){
result+=auxiliary1;
result-=auxiliary2;
result*=auxiliary3;
}while(++loop2<10){
/*
* Statements that will happen after the execution of each cycle
* and only if there is a next cycle.
*/
auxiliary1+=auxiliary3;
auxiliary2*=auxiliary1;
auxiliary3-=auxiliary2;
}
}
return 0;
}
Best regards,
http://ncomputers.org
<http://ncomputers.org/content/code.php?src=suggestions/do%20while.cpp>
--
---
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
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Matthew Woehlke]

Post by Pablo Oliva
do (*statement*)
{
// *A*
}
while (*condition*)
{
// *B*
}

statement;
for (;;)
{
a;
if (!condition)
break;
b;
}

Do I miss something?
--
Matthew

[c***@ncomputers.org]

Thank you very much for your time and your answer!

Break is a jump. if(!condition)break; and for(;condition;) is a double
check of the condition.

Best regards,

http://ncomputers.org

El miércoles, 15 de octubre de 2014 13:17:26 UTC-5, Matthew Woehlke

Post by Matthew Woehlke

Post by Pablo Oliva
do (*statement*)
{
// *A*
}
while (*condition*)
{
// *B*
}

statement;
for (;;)
{
a;
if (!condition)
break;
b;
}
Do I miss something?
--
Matthew

[Matthew Woehlke]

X-Gm-Message-State: ALoCoQmcnaUeS6UotOPFstRIDEaO9fYQ9wAmHC/mOg7nk9XG8g49B+6kV4QiAdS4PNwxbclH0urh
X-Received: by 10.112.62.226 with SMTP id b2mr2372051lbs.0.1413398632669;
Wed, 15 Oct 2014 11:43:52 -0700 (PDT)
X-BeenThere: std-***@isocpp.org
Received: by 10.152.161.234 with SMTP id xv10ls89335lab.13.gmail; Wed, 15 Oct
2014 11:43:50 -0700 (PDT)
X-Received: by 10.153.7.107 with SMTP id db11mr14346415lad.35.1413398630863;
Wed, 15 Oct 2014 11:43:50 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3])
by mx.google.com with ESMTPS id c5si13452773lah.117.2014.10.15.11.43.50
for <std-***@isocpp.org>
(version=TLSv1 cipher=RC4-SHA bits8/128);
Wed, 15 Oct 2014 11:43:50 -0700 (PDT)
Received-SPF: pass (google.com: domain of gclcip-std-***@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip�.91.229.3;
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gclcip-std-***@m.gmane.org>)
id 1XeTY5-0000Qd-Ve
for std-***@isocpp.org; Wed, 15 Oct 2014 20:43:50 +0200
Received: from cpe-67-240-43-113.nycap.res.rr.com ([67.240.43.113])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <std-***@isocpp.org>; Wed, 15 Oct 2014 20:43:49 +0200
Received: from mw_triad by cpe-67-240-43-113.nycap.res.rr.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <std-***@isocpp.org>; Wed, 15 Oct 2014 20:43:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
Lines: 26
X-Complaints-To: ***@ger.gmane.org
X-Gmane-NNTP-Posting-Host: cpe-67-240-43-113.nycap.res.rr.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
In-Reply-To: <56e65c14-0192-48c2-9532-***@isocpp.org>
X-Original-Sender: ***@users.sourceforge.net
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com:
domain of gclcip-std-***@m.gmane.org designates 80.91.229.3 as
permitted sender) smtp.mail=gclcip-std-***@m.gmane.org
Precedence: list
Mailing-list: list std-***@isocpp.org; contact std-proposals+***@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-***@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic%838>, <mailto:std-proposals+***@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
<mailto:std-proposals+***@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+***@googlegroups.com>,
<http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/13921>

El miércoles, 15 de octubre de 2014 13:17:26 UTC-5, Matthew Woehlke

Post by Matthew Woehlke
statement;
for (;;)
{
a;
if (!condition)
break;
b;
}
Do I miss something?

Break is a jump. if(!condition)break; and for(;condition;) is a double
check of the condition.

So is 'while'; I don't see your point. The condition is checked only
once in the above code (note that there is no condition in the 'for').

The only advantage I see to your proposed syntax is the ability to
declare a variable in the 'do' that is local to the loop. I doubt very
much that a core language change would be accepted for so little benefit.
--
Matthew

[c***@ncomputers.org]

Thank you very much for your time and your answer!

(note that there is no condition in the 'for').


Aah! Ok! Yes. The generated code is what we're looking for.

Please note that we suggest this improvement to avoid the usage of tricks
and jumps.

I think, that your trick is very good.

If you had two possible syntax, which would you use and why?

for(unsigned a=0,b;;){
b=1;
if(a)break;
b=0;
}

do(unsigned a=0,b){
b=1;
}while(a){
b=0;
}

Best regards,

http://ncomputers.org

El miércoles, 15 de octubre de 2014 13:43:53 UTC-5, Matthew Woehlke

Post by Matthew Woehlke

Post by c***@ncomputers.org
El miércoles, 15 de octubre de 2014 13:17:26 UTC-5, Matthew Woehlke

Post by Matthew Woehlke
statement;
for (;;)
{
a;
if (!condition)
break;
b;
}
Do I miss something?

Break is a jump. if(!condition)break; and for(;condition;) is a double
check of the condition.

So is 'while'; I don't see your point. The condition is checked only
once in the above code (note that there is no condition in the 'for').
The only advantage I see to your proposed syntax is the ability to
declare a variable in the 'do' that is local to the loop. I doubt very
much that a core language change would be accepted for so little benefit.
--
Matthew

[c***@ncomputers.org]

Thank you very much for your answer and your time!

For example:

unsigned size=10;
unsigned*array=new unsigned[size];

if(size<1)throw "At least one element is required";

do(unsigned a=0){
cout<<array[a];
}
while(++a<10){
cout<<',';
}

It will check condition only one time per cycle. Variables declared in
block A should be visible in block B.

Best regards,

http://ncomputers.org

Post by Pablo Oliva
do (*statement*)
{
// *A*
}
while (*condition*)
{
// *B*
}
will run statement before entering the loop, will perform A
inconditionally one time, will check condition, and if condition holds, it
will run B and then A, then check condition again, and so on?
It seems somewhat contrived. Moving *statement* before the loop seems
semantically equivalent. And having two different code blocks depending on
the same condition appears hard to read.
Also, are variables declared in block B visible in block A, or are they
two completely separated code blocks?

Post by c***@ncomputers.org
Do ... while structure improvement
Sometimes the use of jumps such as: continue, break, goto, calls to a
function, etc. is necessary to avoid the execution of some instructions.
For example: A loop requires auxiliary variables, which change each
cycle, but after the last one, they must either remain unchanged or it is
useless to change them.
This is the case of the seed, warp and swap loops of this solution for
the n queens problem
<http://ncomputers.org/content/code.php?src=n-queens/n-queens.cpp>.
To avoid the use of jumps or tricks on some of these cases, we are
suggesting the below improvement to the *do ... while loop structure*.
*Examples: *Print arrays separating its elements
<http://ncomputers.org/content/code.php?src=examples/do%20while%201.cpp>
/* author: ncomputers.org */
int main(){
unsigned int loop1=0;
unsigned int loop2;
unsigned int result=0;
unsigned int auxiliary1=1,auxiliary2=2,auxiliary3=3;
while(loop1++<1000000000){
/*
* Allow initializers (extra improvement)
*/
do(loop2=0){
result+=auxiliary1;
result-=auxiliary2;
result*=auxiliary3;
}while(++loop2<10){
/*
* Statements that will happen after the execution of each cycle
* and only if there is a next cycle.
*/
auxiliary1+=auxiliary3;
auxiliary2*=auxiliary1;
auxiliary3-=auxiliary2;
}
}
return 0;
}
Best regards,
http://ncomputers.org
<http://ncomputers.org/content/code.php?src=suggestions/do%20while.cpp>
--
---
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
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

[c***@ncomputers.org]

I'll try to answer better your questions.

Post by Pablo Oliva
will run statement before entering the loop, will perform A
inconditionally one time, will check condition, and if condition holds, it
will run B and then A, then check condition again, and so on?

Yes.

It seems somewhat contrived. Moving *statement* before the loop seems

Post by Pablo Oliva
semantically equivalent. And having two different code blocks depending on
the same condition appears hard to read.

It is more readable for us to have statement so:

unsigned a=0;

do(signed a=-1){
//use signed a
signed b;
}
while(condition){
//use signed a
//signed b unvisible.
}

//use unsigned a

Also, are variables declared in block B visible in block A, or are they two

Post by Pablo Oliva
completely separated code blocks?

I wanted to say; variables declared on statement are visible in block A and
block B.

Best regards,

http://ncomputers.org

Post by Pablo Oliva
do (*statement*)
{
// *A*
}
while (*condition*)
{
// *B*
}
will run statement before entering the loop, will perform A
inconditionally one time, will check condition, and if condition holds, it
will run B and then A, then check condition again, and so on?
It seems somewhat contrived. Moving *statement* before the loop seems
semantically equivalent. And having two different code blocks depending on
the same condition appears hard to read.
Also, are variables declared in block B visible in block A, or are they
two completely separated code blocks?

Post by c***@ncomputers.org
Do ... while structure improvement
Sometimes the use of jumps such as: continue, break, goto, calls to a
function, etc. is necessary to avoid the execution of some instructions.
For example: A loop requires auxiliary variables, which change each
cycle, but after the last one, they must either remain unchanged or it is
useless to change them.
This is the case of the seed, warp and swap loops of this solution for
the n queens problem
<http://ncomputers.org/content/code.php?src=n-queens/n-queens.cpp>.
To avoid the use of jumps or tricks on some of these cases, we are
suggesting the below improvement to the *do ... while loop structure*.
*Examples: *Print arrays separating its elements
<http://ncomputers.org/content/code.php?src=examples/do%20while%201.cpp>
/* author: ncomputers.org */
int main(){
unsigned int loop1=0;
unsigned int loop2;
unsigned int result=0;
unsigned int auxiliary1=1,auxiliary2=2,auxiliary3=3;
while(loop1++<1000000000){
/*
* Allow initializers (extra improvement)
*/
do(loop2=0){
result+=auxiliary1;
result-=auxiliary2;
result*=auxiliary3;
}while(++loop2<10){
/*
* Statements that will happen after the execution of each cycle
* and only if there is a next cycle.
*/
auxiliary1+=auxiliary3;
auxiliary2*=auxiliary1;
auxiliary3-=auxiliary2;
}
}
return 0;
}
Best regards,
http://ncomputers.org
<http://ncomputers.org/content/code.php?src=suggestions/do%20while.cpp>
--
---
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
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Markus Grech]

I have suggested the same idea in this thread:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
Note that my suggestion is more general. You may want to look at the
discussion there.

[c***@ncomputers.org]

Thank you very much for your time and your answer!

We're now two, who proposes the same improvement!

I think, that the other two ideas are also good!

Best regards,

ncomputers.org

Post by Markus Grech
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
Note that my suggestion is more general. You may want to look at the
discussion there.

[z***@gmail.com]

I'm late to the party (and maybe this has already made it in), but I'd also
like to see 'do(init) { ... } while(predicate);', to prevent 'init' scope
leakage.

Analogously, it would be good to have (if we don't have it yet) 'try(init)
{....} catch(blah) {...} catch(blaz) {....}', where the scope 'init'
extends to the last catch block.

--Zem

Post by c***@ncomputers.org
Thank you very much for your time and your answer!
We're now two, who proposes the same improvement!
I think, that the other two ideas are also good!
Best regards,
ncomputers.org

Post by Markus Grech
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
Note that my suggestion is more general. You may want to look at the
discussion there.

[Richard Smith]

Post by z***@gmail.com
I'm late to the party (and maybe this has already made it in), but I'd
also like to see 'do(init) { ... } while(predicate);', to prevent 'init'
scope leakage.

`do` does not have mandatory braces, so parsing that would be quite
challenging, and it would probably introduce lots of syntactic ambiguities.
For example:

int **p, **x;
void f() {
do (int (**p) = x) (*p)[0] = 1; while (true);
}

... would be ambiguous between declaring a variable named p in a
do-initializer and using it in the body, and a function-call expression
whose callee is (int (**p) = x) and whose argument is *p.

Post by z***@gmail.com
Analogously, it would be good to have (if we don't have it yet) 'try(init)
{....} catch(blah) {...} catch(blaz) {....}', where the scope 'init'
extends to the last catch block.

This wouldn't be ambiguous, but is it useful? Do you have a concrete use
case for this?

Post by z***@gmail.com
--Zem

Post by c***@ncomputers.org
Thank you very much for your time and your answer!
We're now two, who proposes the same improvement!
I think, that the other two ideas are also good!
Best regards,
ncomputers.org

Post by Markus Grech
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
Note that my suggestion is more general. You may want to look at the
discussion there.

--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org?utm_medium=email&utm_source=footer>
.

[z***@gmail.com]

Good point about the introduced ‘do’ ambiguity. Looking at your example, I’m not even sure the ambiguity could be resolved _semantically_. Shame ☹



I introduced the try-catch idea merely for “completeness”/orthogonality (I’m not a heavy user of exceptions myself), but the idea is as follows: You acquire some value from somewhere and attempt to perform computation on it, but if something goes awry, you throw it for someone else to handle:



try (MyObject val = some_acquired_value()) {

do_something_useful_with(val);

}

catch ( OverflowException e) {

throw(val); // so someone else can do something useful with it

}

// but you don’t want val lying around here





From: Richard Smith <***@metafoo.co.uk>
Sent: Monday, October 22, 2018 7:29 PM
To: std-***@isocpp.org
Cc: ***@ncomputers.org
Subject: Re: [std-proposals] Re: Do ... while structure improvement



On Fri, 19 Oct 2018 at 15:24, <***@gmail.com> wrote:

I'm late to the party (and maybe this has already made it in), but I'd also like to see 'do(init) { ... } while(predicate);', to prevent 'init' scope leakage.



`do` does not have mandatory braces, so parsing that would be quite challenging, and it would probably introduce lots of syntactic ambiguities. For example:



int **p, **x;

void f() {

do (int (**p) = x) (*p)[0] = 1; while (true);

}



... would be ambiguous between declaring a variable named p in a do-initializer and using it in the body, and a function-call expression whose callee is (int (**p) = x) and whose argument is *p.



Analogously, it would be good to have (if we don't have it yet) 'try(init) {....} catch(blah) {...} catch(blaz) {....}', where the scope 'init' extends to the last catch block.



This wouldn't be ambiguous, but is it useful? Do you have a concrete use case for this?



--Zem

On Thursday, October 16, 2014 at 9:44:59 AM UTC-7, ***@ncomputers.org <mailto:***@ncomputers.org> wrote:

Thank you very much for your time and your answer!

We're now two, who proposes the same improvement!

I think, that the other two ideas are also good!

Best regards,

ncomputers.org <http://ncomputers.org>

El jueves, 16 de octubre de 2014 01:43:41 UTC-5, Markus Grech escribió:

I have suggested the same idea in this thread: https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA

Note that my suggestion is more general. You may want to look at the discussion there.
--
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+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org?utm_medium=email&utm_source=footer> .
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/i-0stW2WkXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com?utm_medium=email&utm_source=footer> .

['ncomputers.org' via ISO C++ Standard - Future Proposals]

Hi,

Thank you very much for taking a look to this some years after it was
written.

I have been making an effort for keeping the original idea alive here:
https://ncomputers.org/dowhile

I will reply more later.

Example of ASM code:

do(int rax=0){//block A}

while(rax!=100){//block B}

...........

mov $0,%rax

do:

#block A

cmp %rax,$100

je end

#block B

jmp do

end:

...........

Best regards,

Oliver

Good point about the introduced ‘do’ ambiguity.  Looking at your
example, I’m not even sure the ambiguity could be resolved
_/semantically/_.  Shame ☹
I introduced the try-catch idea merely for
“completeness”/orthogonality (I’m not a heavy user of exceptions
myself), but the idea is as follows:  You acquire some value from
somewhere and attempt to perform computation on it, but if something
try (MyObject val = some_acquired_value()) {
  do_something_useful_with(val);
}
catch ( OverflowException e) {
  throw(val);  // so someone else can do something useful with it
}
// but you don’t want val lying around here
*Sent:* Monday, October 22, 2018 7:29 PM
*Subject:* Re: [std-proposals] Re: Do ... while structure improvement
I'm late to the party (and maybe this has already made it in), but
I'd also like to see 'do(init) { ... } while(predicate);', to
prevent 'init' scope leakage.
`do` does not have mandatory braces, so parsing that would be quite
challenging, and it would probably introduce lots of syntactic
int **p, **x;
void f() {
  do (int (**p) = x) (*p)[0] = 1; while (true);
}
... would be ambiguous between declaring a variable named p in a
do-initializer and using it in the body, and a function-call
expression whose callee is (int (**p) = x) and whose argument is *p.
Analogously, it would be good to have (if we don't have it yet)
'try(init) {....} catch(blah) {...} catch(blaz) {....}', where the
scope 'init' extends to the last catch block.
This wouldn't be ambiguous, but is it useful? Do you have a concrete use case for this?
--Zem
On Thursday, October 16, 2014 at 9:44:59 AM UTC-7,
Thank you very much for your time and your answer!
We're now two, who proposes the same improvement!
I think, that the other two ideas are also good!
Best regards,
ncomputers.org <http://ncomputers.org>
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
<https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposals/O1rpMw2dNwA>
Note that my suggestion is more general. You may want to
look at the discussion there.
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/i-0stW2WkXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Richard Hodges]

Post by z***@gmail.com
Good point about the introduced ‘do’ ambiguity. Looking at your example,
I’m not even sure the ambiguity could be resolved _*semantically*_.
Shame ☹
I introduced the try-catch idea merely for “completeness”/orthogonality
You acquire some value from somewhere and attempt to perform computation on
try (MyObject val = some_acquired_value()) {
do_something_useful_with(val);
}
catch ( OverflowException e) {
throw(val); // so someone else can do something useful with it
}
// but you don’t want val lying around here

This is an interesting case, because for me one of the most annoying things
about c++'s try blocks is that the variables *don't* escape the braces.
What I mean to say is that very often you do want at least one of the
variables "lying around here" :)

consider this impossible case:

NotDefaultConstructible x; // illegal
try
{
x = NotDefaultConstructible::construct_may_throw(...);
x.something_that_may_throw();
y = x.some_property();
}
catch(...)
{
x = NotDefaultConstructible::recovery_mode();
}

// now use x;

We currently cannot write this - we are forced to hold x in an optional or
unique_ptr - which while solving the language expression problem, has
nothing to do with the intent of the algorithm - x is simply not logically
optional in this case.

The answer of course is to wrap the operations involving x into a few
smaller functions. But sometimes we don't want to. Essentially we're forced
into something like this:

auto make_x = [&y] {
try {
x = NotDefaultConstructible::construct_may_throw(...);
x.something_that_may_throw();
y = x.some_property();
return x;
}
catch(...) {
return NotDefaultConstructible::recovery_mode();
}
};

auto x = make_x();

// use x

I think there are (at least) two opposing arguments here:

1. Obviously you should be forced to express this code in a function
because the more single-responsibility functions you have the less
complexity you have.
2. This action is so trivial that I don't want to be forced to express it
through an artificial function.

Post by z***@gmail.com
*Sent:* Monday, October 22, 2018 7:29 PM
*Subject:* Re: [std-proposals] Re: Do ... while structure improvement
I'm late to the party (and maybe this has already made it in), but I'd
also like to see 'do(init) { ... } while(predicate);', to prevent 'init'
scope leakage.
`do` does not have mandatory braces, so parsing that would be quite
challenging, and it would probably introduce lots of syntactic ambiguities.
int **p, **x;
void f() {
do (int (**p) = x) (*p)[0] = 1; while (true);
}
... would be ambiguous between declaring a variable named p in a
do-initializer and using it in the body, and a function-call expression
whose callee is (int (**p) = x) and whose argument is *p.
Analogously, it would be good to have (if we don't have it yet) 'try(init)
{....} catch(blah) {...} catch(blaz) {....}', where the scope 'init'
extends to the last catch block.
This wouldn't be ambiguous, but is it useful? Do you have a concrete use case for this?
--Zem
Thank you very much for your time and your answer!
We're now two, who proposes the same improvement!
I think, that the other two ideas are also good!
Best regards,
ncomputers.org
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA
Note that my suggestion is more general. You may want to look at the discussion there.
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/i-0stW2WkXs/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/006801d46d51%24826da7b0%248748f710%24%40gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/006801d46d51%24826da7b0%248748f710%24%40gmail.com?utm_medium=email&utm_source=footer>
.

--
Richard Hodges
***@gmail.com
office: [phone]
home: [phone]
mobile: [phone] (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

[z***@gmail.com]

But wait, I think I may have found a way to salvage my do-while proposal. Currently, the C++ standard specifies






do <http://nongnu.org/hcb/#statement> statement while ( <http://nongnu.org/hcb/#expression> expression ) ;



But what if we also added






do( <http://nongnu.org/hcb/#for-init-statement> init-statement ) <http://nongnu.org/hcb/#statement> compound_statement while ( <http://nongnu.org/hcb/#expression> expression ) ;



Compound statements require braces and so the syntactic/semantic ambiguity is removed.



It is a bit clunky, but would work.



From: Richard Hodges <***@gmail.com>
Sent: Sunday, October 28, 2018 1:33 AM
To: std-***@isocpp.org
Subject: Re: [std-proposals] Re: Do ... while structure improvement





On Fri, 26 Oct 2018 at 19:29, <***@gmail.com <mailto:***@gmail.com> > wrote:

Good point about the introduced ‘do’ ambiguity. Looking at your example, I’m not even sure the ambiguity could be resolved _semantically_. Shame ☹



I introduced the try-catch idea merely for “completeness”/orthogonality (I’m not a heavy user of exceptions myself), but the idea is as follows: You acquire some value from somewhere and attempt to perform computation on it, but if something goes awry, you throw it for someone else to handle:



try (MyObject val = some_acquired_value()) {

do_something_useful_with(val);

}

catch ( OverflowException e) {

throw(val); // so someone else can do something useful with it

}

// but you don’t want val lying around here



This is an interesting case, because for me one of the most annoying things about c++'s try blocks is that the variables don't escape the braces. What I mean to say is that very often you do want at least one of the variables "lying around here" :)



consider this impossible case:



NotDefaultConstructible x; // illegal

try

{

x = NotDefaultConstructible::construct_may_throw(...);

x.something_that_may_throw();

y = x.some_property();

}

catch(...)

{

x = NotDefaultConstructible::recovery_mode();

}



// now use x;



We currently cannot write this - we are forced to hold x in an optional or unique_ptr - which while solving the language expression problem, has nothing to do with the intent of the algorithm - x is simply not logically optional in this case.



The answer of course is to wrap the operations involving x into a few smaller functions. But sometimes we don't want to. Essentially we're forced into something like this:



auto make_x = [&y] {

try {

x = NotDefaultConstructible::construct_may_throw(...);

x.something_that_may_throw();

y = x.some_property();

return x;

}

catch(...) {

return NotDefaultConstructible::recovery_mode();

}

};



auto x = make_x();



// use x



I think there are (at least) two opposing arguments here:



1. Obviously you should be forced to express this code in a function because the more single-responsibility functions you have the less complexity you have.

2. This action is so trivial that I don't want to be forced to express it through an artificial function.











From: Richard Smith <***@metafoo.co.uk <mailto:***@metafoo.co.uk> >
Sent: Monday, October 22, 2018 7:29 PM
To: std-***@isocpp.org <mailto:std-***@isocpp.org>
Cc: ***@ncomputers.org <mailto:***@ncomputers.org>
Subject: Re: [std-proposals] Re: Do ... while structure improvement



On Fri, 19 Oct 2018 at 15:24, <***@gmail.com <mailto:***@gmail.com> > wrote:

I'm late to the party (and maybe this has already made it in), but I'd also like to see 'do(init) { ... } while(predicate);', to prevent 'init' scope leakage.



`do` does not have mandatory braces, so parsing that would be quite challenging, and it would probably introduce lots of syntactic ambiguities. For example:



int **p, **x;

void f() {

do (int (**p) = x) (*p)[0] = 1; while (true);

}



... would be ambiguous between declaring a variable named p in a do-initializer and using it in the body, and a function-call expression whose callee is (int (**p) = x) and whose argument is *p.



Analogously, it would be good to have (if we don't have it yet) 'try(init) {....} catch(blah) {...} catch(blaz) {....}', where the scope 'init' extends to the last catch block.



This wouldn't be ambiguous, but is it useful? Do you have a concrete use case for this?



--Zem

On Thursday, October 16, 2014 at 9:44:59 AM UTC-7, ***@ncomputers.org <mailto:***@ncomputers.org> wrote:

Thank you very much for your time and your answer!

We're now two, who proposes the same improvement!

I think, that the other two ideas are also good!

Best regards,

ncomputers.org <http://ncomputers.org>

El jueves, 16 de octubre de 2014 01:43:41 UTC-5, Markus Grech escribió:

I have suggested the same idea in this thread: https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/O1rpMw2dNwA

Note that my suggestion is more general. You may want to look at the discussion there.
--
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+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0ed6ec-12fb-415c-b940-5c66c27dfeb4%40isocpp.org?utm_medium=email&utm_source=footer> .
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/i-0stW2WkXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm2eWDcUcVgDaOQg4RBrh4UGmMHfgGDuPWeYKnZ-9sSfA%40mail.gmail.com?utm_medium=email&utm_source=footer> .
--
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+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/006801d46d51%24826da7b0%248748f710%24%40gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/006801d46d51%24826da7b0%248748f710%24%40gmail.com?utm_medium=email&utm_source=footer> .
--
Richard Hodges

***@gmail.com <mailto:***@gmail.com>

office: [phone]

home: [phone]

mobile: [phone] (this will be *expensive* outside Andorra!)

skype: madmongo

facebook: hodges.r
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/i-0stW2WkXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+***@isocpp.org <mailto:std-proposals+***@isocpp.org> .
To post to this group, send email to std-***@isocpp.org <mailto:std-***@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYxZFCkfFe_0sdJJMRZk9WZUV7F9XZ3RSiUY4W-w2sWnw%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYxZFCkfFe_0sdJJMRZk9WZUV7F9XZ3RSiUY4W-w2sWnw%40mail.gmail.com?utm_medium=email&utm_source=footer> .

[Matthew Woehlke]

Post by z***@gmail.com
I'm late to the party (and maybe this has already made it in), but I'd also
like to see 'do(init) { ... } while(predicate);', to prevent 'init' scope
leakage.
Analogously, it would be good to have (if we don't have it yet) 'try(init)
{....} catch(blah) {...} catch(blaz) {....}', where the scope 'init'
extends to the last catch block.

If we only had a `with` statement, the value of all these additions
would be greatly reduced...

#define with(decl) if(decl; true)

...except maybe for `if` ;-).

That said, one "nice" reason to consider a `with` as an actual language
extension is that it could (also) take a statement and lifetime-extend
its value:

with (acquire{resource}) // not destroyed immediately

(AFAICT there is no way to write a single macro that can do both.)

[Douglas Boffey]

One thing that seems to be overlooked is the similarity to:


do (/*statement*/) {

/*A*/
} while (/*condition*/); {
/*B*/
}


(i.e. differing in just a semicolon), which is correctly legal, but has
quite different semantics.

[Matthew Woehlke]

Post by Douglas Boffey
do (/*statement*/) {
/*A*/
} while (/*condition*/); {
/*B*/
}
(i.e. differing in just a semicolon), which is correctly legal, but has
quite different semantics.

True, but one can also write:

if (condition); {
...stuff...
}

...right now, which is similarly perfectly legal and just as broken. (In
fact, I *did* this - by accident, of course - just a few days ago.) But
no one is proposing to somehow ban such a construct.

I'd consider the above a weak argument against. (I'm still opposed to
it, but more for other, previously mentioned reasons.)
--
Matthew

[c***@ncomputers.org]

Thank you for your time and your answer!

I don't understand exactly, which purpose does this syntax have?

#include<iostream>
using namespace std;

int main(){
if(0);{
cout<<"here"<<endl;
}
}

Best regards,

ncomputers.org

Post by Matthew Woehlke

Post by Douglas Boffey
do (/*statement*/) {
/*A*/
} while (/*condition*/); {
/*B*/
}
(i.e. differing in just a semicolon), which is correctly legal, but has
quite different semantics.

if (condition); {
...stuff...
}
...right now, which is similarly perfectly legal and just as broken. (In
fact, I *did* this - by accident, of course - just a few days ago.) But
no one is proposing to somehow ban such a construct.
I'd consider the above a weak argument against. (I'm still opposed to
it, but more for other, previously mentioned reasons.)
--
Matthew