Tuesday, April 16, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 02:57PM -0400

I'm curious what people's thought are on this idea. It allows the initial
test on the for {..} block to enter the block, or fall-through to the else
clause. Subsequent tests on the for {..} block that fail simply exit out
past the last }.
 
for (init; test; incr)
{
// for code here
 
} else {
// else code here
}
 
It's the equivalent of:
 
init;
if (test)
{
goto skip_first_iteration;
for ( ; test; incr)
{
skip_first_iteration:
// for code here
}
 
} else {
// else code here
}
 
Seems a natural progression. One I could use quite often due to the
need to test the conditions outside of the for {..} block today before
entering it with then-known valid data. If the test for a valid state
could be incorporated into the generic iterative test, and the else
clause added, it would be more natural methinks.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 03:06PM -0400

On 4/16/2019 2:57 PM, Rick C. Hodgin wrote:
>         for ( ; test; incr)
>         {
> skip_first_iteration:
 
Should be "skip_first_test:".
 
> entering it with then-known valid data.  If the test for a valid state
> could be incorporated into the generic iterative test, and the else
> clause added, it would be more natural methinks.
 
Another variant could be:
 
for_if (test1; init; test2; incr)
{
} else {
}
 
test1 is the if (test1) test, and if it fails, goes to the else. The
test2 is the iterative test which processes like normal. This one could
be used when test1 and test2 are different, or are not overlapping.
 
Of course "else if" blocks could also be used, and I think also a new
concept of "else for" block could also be used:
 
for (init1; test1; incr1)
{
// First for code here
 
} else for (init2; test2; incr2) {
// Second for code here
 
} else for (init3; test3; incr3) {
// Third for code here
 
} else {
// Fallthrough code
}
 
Same for:
 
for_if (test1_1; init1; test1_2; incr1)
{
// First for_if code here
 
} else for_if (test1_1; init1; test1_2; incr1) {
// Second for_if code here
 
} else for_if (test1_1; init1; test1_2; incr1) {
// Third for_if code here
 
} else {
// Fallthrough code
}
 
And, of course, for {..} and for_if {..} blocks could be intermixed.
 
--
Rick C. Hodgin
Bart <bc@freeuk.com>: Apr 16 08:27PM +0100

On 16/04/2019 19:57, Rick C. Hodgin wrote:
>         // else code here
>     }
 
> Seems a natural progression.
 
Some languages have for-else, but that's not how it's used.
 
The use-cases in those other languages are more useful, and easier to
understand, than what you have. There, a for-else loop like this:
 
for (A; B; C) {
D;
if (X) break;
} else {E;}
 
is equivalent to:
 
for (A; B; C) {
D;
if (X) goto skipelse;
}
E;
skipelse:
 
The else-clause is executed on normal loop terminated. But not when
terminated by 'break'.
 
Note that when B starts off as false, then this is equivalent to your
version: it will just execute E. But when B starts as true, then some
iterations are executed before E, unlike yours that will do nothing
special when the loop ends normally after 1+ iterations.
 
(Note also that 'for(){} else' has some syntactic issues in C, as the
'else' could taken to belong to the last if-block at the same block
level. A rule change to make it belong to the last 'if' or 'for' would
break existing code.)
Christian Gollwitzer <auriocus@gmx.de>: Apr 16 09:34PM +0200

Am 16.04.19 um 20:57 schrieb Rick C. Hodgin:
> test on the for {..} block to enter the block, or fall-through to the else
> clause.  Subsequent tests on the for {..} block that fail simply exit out
> past the last }.
 
Such a construct exists in the Python language:
 
http://book.pythontips.com/en/latest/for_-_else.html
 
(and also with while loops). It is occasionally useful, but more often
then actually used, it is asked by confused Python learners what exactly
this means, under which conditions the else block will run, and how it
is different from just putting something after a regular for block.
 
Christian
Bart <bc@freeuk.com>: Apr 16 08:35PM +0100

On 16/04/2019 20:06, Rick C. Hodgin wrote:
 
>     } else {
>     }
 
> test1 is the if (test1) test, and if it fails, goes to the else.
 
I thought you wanted 'init' to be executed first? Otherwise there seems
little point to this, as it is exactly equivalent to:
 
if (test1) for (init; test2; incr)
{
} else {
}
 
which can be done right now. And without encouraging people to abuse
for-headers even more than they already do. (I know how compulsive it is
to cram as much in there as possible.)
 
  The
 
>     } else {
>         // Fallthrough code
>     }
 
 
So, if test1 is false to start with it will do try the second for; and
if test2 is false to start it will try the third for?
 
Do you have any actual use-cases for this?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 04:54PM -0400

On 4/16/2019 3:34 PM, Christian Gollwitzer wrote:
> means, under which conditions the else block will run, and how it is
> different from just putting something after a regular for block.
 
>     Christian
 
 
Good to hear. Thank you, Christian.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 05:02PM -0400

On 4/16/2019 3:35 PM, Bart wrote:
>      {
>      } else {
>      }
 
I think you can already do your syntax in C/C++.
 
if (test1)
for (...)
{
// for code
}
 
else {
// else code
}
 
> which can be done right now. And without encouraging people to abuse
> for-headers even more than they already do. (I know how compulsive it is to
> cram as much in there as possible.)
 
The purpose of the for_if would be to test the outer condition in a way
that's part of the for block, allowing it to then fall through to an
else clause which could be another for_if or for block, with the second
test being one which falls out of the entire loop if it is entered one
time.
 
>>      }
 
> So, if test1 is false to start with it will do try the second for; and if
> test2 is false to start it will try the third for?
 
It would be used in cases where part of the test1 would be overlapping.
 
if (x)
{
for (init; x && x->member != whatever; iter)
{
// Process
 
// Move through the pointer chain
x = x->next;
}
}
 
In this case, you only want to execute the init code if x is valid to
start out with.
 
> Do you have any actual use-cases for this?
 
I came across a need for it today in my code, which is why / how it
occurred to me.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Apr 16 11:32PM +0200

On 16/04/2019 21:34, Christian Gollwitzer wrote:
> this means, under which conditions the else block will run, and how it
> is different from just putting something after a regular for block.
 
>     Christian
 
That is new to me. I can see it being useful in some cases (like the
examples shown in that link), though I am not convinced it is very
clear. I think Python experts would be confused by it, never mind
Python learners.
leigh.v.johnston@googlemail.com: Apr 16 02:48AM -0700

On Monday, April 15, 2019 at 6:56:01 PM UTC+1, Alf P. Steinbach wrote:
> They're just annoyingly needlessly impractically verbose in C++. And the
> committee drags its feet, going by quarter-measures, where C++17 just
> allows you to not redundantly repeat the word `using` for each item.

If you ever want me to look at your code then:
1) I don't want to see any of this $ macro bollocks;
2) I don't want to see any using directives, use std:: prefix whenever something from the stdlib is used as it makes the code clearer and easier to understand;
3) I don't want to see overuse of the auto return type / arrow notation. You are deliberately trying to irritate by using it for main() and for other things that are NOT what it was designed for (it was primarily designed for a subset of function templates).
 
/Leigh
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 16 12:51PM +0200

> 1) I don't want to see any of this $ macro bollocks;
> 2) I don't want to see any using directives, use std:: prefix whenever something from the stdlib is used as it makes the code clearer and easier to understand;
> 3) I don't want to see overuse of the auto return type / arrow notation. You are deliberately trying to irritate by using it for main() and for other things that are NOT what it was designed for (it was primarily designed for a subset of function templates).
 
No, I don't want you looking at my code. The result of that has always
been sour commentary like the above, asserting some pretty subjective
ideas about things, with nothing useful to me or others. Which leads me
to believe that you /have/ looked at that code. :)
 
But I don't want you to waste time on your universal compiler either
(even if you restrict that effort to a VM, Mozilla is doing that).
 
Please, instead finish up a working first version of the NeoGfx library,
and let students and hobbyists, maybe also small firms, use it for free,
e.g. like Visual Studio.
 
 
Cheers!,
 
- Alf
leigh.v.johnston@googlemail.com: Apr 16 04:22AM -0700

On Tuesday, April 16, 2019 at 11:51:34 AM UTC+1, Alf P. Steinbach wrote:
 
> Please, instead finish up a working first version of the NeoGfx library,
> and let students and hobbyists, maybe also small firms, use it for free,
> e.g. like Visual Studio.
 
The scripting engine is an important part of neoGFX and my universal compiler is an important part of the scripting engine.
 
/Leigh
"Öö Tiib" <ootiib@hot.ee>: Apr 16 05:56AM -0700


> The scripting engine is an important part of neoGFX and my universal compiler is an important part of the scripting engine.
 
Why you can't just embed some existing (like lua or javascript)
engine as first step? That would take only a tiny bit of time
compared to implementing and testing and getting some
"universal compiler" feature rich, efficient and defect free
enough to be useful for anything.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 16 04:59PM +0100

On 16/04/2019 13:56, Öö Tiib wrote:
> compared to implementing and testing and getting some
> "universal compiler" feature rich, efficient and defect free
> enough to be useful for anything.
 
You are underestimating both the power of "NIH" and my abilities Öö Tiib! :D
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 16 01:31PM -0700

On 4/10/2019 2:08 PM, Alf P. Steinbach wrote:
>> help. Humm...
 
> Done. It's just that I prefer coding up things with the macros, cause
> it's less to write and less to read. Thanks.
 
[...]
> - Alf (no change of behavior: works with g++, crashes with MSVC)
 
A thread that locks a mutex, MUST be same thread that unlocks it. I am
not exactly sure what you are doing here.
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 16 12:29AM -0400

On 4/15/19 6:22 PM, Robert Wessel wrote:
...
> implementation where those don't generate the same string as printf
> and iostream is probably classifiable as a bit perverse. Probably
> need to do some testing.
The way you said that isn't quite right, but it's possible that what you
meant to say is correct.
 
std::strtod(), std::nan(), and std::istream::operator>>() should all
produce the same NaN from a given n-char-sequence, since the behavior of
the last two is defined in terms of the behavior of strtod(). An
implementation where that was not true would be non-conforming.
 
std::sprintf(), std::num_put::do_put(), and std::ostream::operator<<()
should produce the same n-char-sequence (if any) from any given NaN,
since each function is that series has behavior defined in terms of the
preceding one. An implementation where that was not true would be
non-conforming.
 
Nothing mandates that sprintf() must reverse the conversion performed by
strtod() - the code
 
std::sprintf(buffer, "%f",
std::strtod("NAN(n-char-sequence)")
 
doesn't necessarily fill buffer with "NAN(n-char-sequence)". However, I
would agree that an implementation which chooses the option of producing
an n-char-sequence, and which doesn't choose to produce the same
sequence as was passed to strtod(), could be classified as "a bit perverse".
 
Do those statements match what you intended to say?
"Öö Tiib" <ootiib@hot.ee>: Apr 16 05:26AM -0700

> implement them, and need to handle things like Infs and NaNs.
 
> IOW, I'm trying to figure out what users of this library might be
> expecting in those cases.
 
Do I understand it correctly that you need to implement both
istream>> and ostream<< for your own type that does not
need to use the mess around I/O of fundamental floating
types but you want these to look very similar to fundamental
floating point types? Then it is more about expectations of
potential user base (who are rarely language lawyers)?

I would (as user of such type) expect << to output nan, inf
and -inf with uppercase flag of stream not enabled (default
and std::nouppercase) and NAN, INF and -INF with it
enabled (std::uppercase). Also I would expect std::showpos
should cause positive infinity to be output as +inf or +INF.
The >> I would expect to parse all those forms regardless
of flags.
 
I would dislike indication of NaN payload. There are
multitude of reasons: It is unused by program logic
on vast majority of cases. It increases size of text that
is visually garbage but needs producing and handling
code. IOW waste of both storage and performance
for no gain on vast majority of cases.
Robert Wessel <robertwessel2@yahoo.com>: Apr 16 11:31AM -0500

On Tue, 16 Apr 2019 00:29:51 -0400, James Kuyper
>an n-char-sequence, and which doesn't choose to produce the same
>sequence as was passed to strtod(), could be classified as "a bit perverse".
 
>Do those statements match what you intended to say?
 
 
Yes, badly worded on my part (at best).
Robert Wessel <robertwessel2@yahoo.com>: Apr 16 12:19PM -0500

On Tue, 16 Apr 2019 05:26:52 -0700 (PDT), 嘱 Tiib <ootiib@hot.ee>
wrote:
 
>types but you want these to look very similar to fundamental
>floating point types? Then it is more about expectations of
>potential user base
 
 
Yes.
 
 
> (who are rarely language lawyers)?
 
 
I'm not expecting them to be language lawyers, but I do think it
worthwhile to be as consistent with the rest of the (C++)
implementation as reasonable. If a calculation results in an infinity
with normal FP types, or with this library, it would be least
surprising to users if they both produced the same string after
formatting. It may not be a big deal for many users, but why
introduce unnecessary differences for no good reason?
 

>should cause positive infinity to be output as +inf or +INF.
>The >> I would expect to parse all those forms regardless
>of flags.
 
 
As James pointed out, the standard allows "infinity" as well as "inf".
It also appears that there are more than a few non-standard
interpretations floating around. My current thinking is to dig the
local output formatting out of sprintf. That would appear to be
fairly simple for the various forms of infinity, there's a bit more
complexity with NaNs. I'm less clear on what I want to do for
conversions from *text* format.
 
 
>is visually garbage but needs producing and handling
>code. IOW waste of both storage and performance
>for no gain on vast majority of cases.
 
 
I'm waffling on this. I don't think NaN payloads have much storage or
performance impact (the increased code footprint for producing them
notwithstanding) for most applications. They, after all, would only
happen if there are actual NaNs. I don't think it's unreasonable to
support formatting NaN payloads if the implementation does so for
normal floats.
 
This may ultimately need some configuration options, but I'd like to
be able to provide good defaults for most cases.
Jeff-Relf.Me @.: Apr 10 08:02PM -0700

Jeff-Relf.Me @.: Apr 10 09:47PM -0700

SergIo <invalid@invalid.com>: Apr 11 12:51AM -0500


> Was it this line:
 
> PageUp ? ( --PP < BB ? PP = EE, iFolder = Cnt, rFolders = 0 : ( iFolder--, rFolders++ ) ) : PageDwn ? ( ++PP > EE ? PP = BB, rFolders = Cnt, iFolder = 0 : ( iFolder++, !--rFolders ) ) : 0 ;
 
> What languages have you programmed in ?
 
early ones;
CP/M DOS 1.25h, ever use PIP ?
fortran, (8 byte precision, ugh, ugly) fortran 88, pascal (the $25 one)
use linux mint now on several computers (formally windows)
have two servers in garage, one is very linux low power you can install
in a wall, the other is a full up Centos HP prolient G6 w 64Gbyte RAM, 4
xeon collecting dust-too loud if above 75F. even have raspberry pi 3
b+ is good, but you have to heat sink the processer.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 11 03:09AM

> I want to know how you came to that conclusion.
 
> Was it this line:
 
> PageUp ? ( --PP < BB ? PP = EE, iFolder = Cnt, rFolders = 0 : ( iFolder--, rFolders++ ) ) : PageDwn ? ( ++PP > EE ? PP = BB, rFolders = Cnt, iFolder = 0 : ( iFolder++, !--rFolders ) ) : 0 ;
 
Garbage...
 
--
press any key to continue or any other to quit...
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 10 09:03PM -0700

> (my reputation becoming -1), and scolded for not just using an
> array. I then asked on comp.lang.c++ and comp.lang.c++.moderated,
> and it was answered by Bo Persson.
 
An unfortunate aspect of stackoverflow is its catering to a
culture of a continual popularity contest. I don't participate
on stackoverflow, and experiences like this one are part of the
reason why.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 11 04:07AM

> culture of a continual popularity contest. I don't participate
> on stackoverflow, and experiences like this one are part of the
> reason why.
I don't like stackoverflow at all...
 
--
press any key to continue or any other to quit...
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 10 03:39PM +0200

On 10.04.2019 15:28, Thiago Adams wrote:
 
> Everyone is invited, Bart, BGB, Jacob.
> You are invited as well but you will be the only person
> whose messages will be moderated (and you know why).
 
:)
 
Maybe we all should migrate to a Google Group equivalent.
 
After all the comp.std.c++ folks did (I believe the groups are
referenced over at isocpp.com).
 
This suggestion just half in jest.
 
 
Cheers!,
 
- Alf
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)