Thursday, April 8, 2021

Digest for comp.lang.c++@googlegroups.com - 18 updates in 4 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Apr 08 05:50PM -0500

"All C++20 core language features with examples" by Oleksandr Koval
https://oleksandrkvl.github.io/2021/04/02/cpp-20-overview.html
 
"The story behind this article is very simple, I wanted to learn about
new C++20 language features and to have a brief summary for all of them
on a single page. So, I decided to read all proposals and create this
"cheat sheet" that explains and demonstrates each feature. This is not a
"best practices" kind of article, it serves only demonstrational
purpose. Most examples were inspired or directly taken from
corresponding proposals, all credit goes to their authors and to members
of ISO C++ committee for their work. Enjoy!"
 
That is a lot of examples.
 
Lynn
Juha Nieminen <nospam@thanks.invalid>: Apr 08 05:40PM

> A little demo: should the program read in incorrect numbers happily, or
> should it report an error?
 
I think it's not bad that the standard library offers the choice.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 08 09:41PM +0300

08.04.2021 20:40 Juha Nieminen kirjutas:
>> A little demo: should the program read in incorrect numbers happily, or
>> should it report an error?
 
> I think it's not bad that the standard library offers the choice.
 
You don't need scanf() to get incorrect numbers, you can easily have
them also with C++ streams (a design bug IMO, stream exceptions should
be on by default, but that's just me):
 
 
#include <iostream>
#include <string>
#include <sstream>
 
int main() {
const char* buffer = "12345678912345678";
int x;
std::istringstream is(buffer);
is >> x;
std::cout << "istream produced: " << x << "\n";
}
 
Output:
istream produced: 2147483647
Real Troll <real.troll@trolls.com>: Apr 08 09:28PM +0100

On 08/04/2021 19:41, Paavo Helde wrote:
 
> Output:
> istream produced: 2147483647
 
That's because you are calling an int.  However try this:
 
#include <iostream>
#include <string>
#include <sstream>
 
using namespace std;
 
int main() {
const char* buffer = "1234567890123456789";
long long x;
istringstream is(buffer);
is >> x;
cout << "istream produced: " << x << "\n";
return 0;
}
Real Troll <real.troll@trolls.com>: Apr 08 09:28PM +0100

On 08/04/2021 19:41, Paavo Helde wrote:
 
> Output:
> istream produced: 2147483647
 
That's because you are calling an int.  However try this:
 
#include <iostream>
#include <string>
#include <sstream>
 
using namespace std;
 
int main() {
const char* buffer = "1234567890123456789";
long long x;
istringstream is(buffer);
is >> x;
cout << "istream produced: " << x << "\n";
return 0;
}
Real Troll <real.troll@trolls.com>: Apr 08 09:28PM +0100

On 08/04/2021 19:41, Paavo Helde wrote:
 
> Output:
> istream produced: 2147483647
 
That's because you are calling an int.  However try this:
 
#include <iostream>
#include <string>
#include <sstream>
 
using namespace std;
 
int main() {
const char* buffer = "1234567890123456789";
long long x;
istringstream is(buffer);
is >> x;
cout << "istream produced: " << x << "\n";
return 0;
}
Paavo Helde <myfirstname@osa.pri.ee>: Apr 08 11:52PM +0300

08.04.2021 23:28 Real Troll kirjutas:
> cout << "istream produced: " << x << "\n";
> return 0;
> }
 
Sorry, my bad. Here is a corrected version:
 
#include <iostream>
#include <string>
#include <sstream>
 
using namespace std;
 
int main() {
const char* buffer =
"123456789012345678912345678901234567891234567890123456789";
long long x;
istringstream is(buffer);
is >> x;
cout << "istream produced: " << x << "\n";
return 0;
}
Real Troll <real.troll@trolls.com>: Apr 08 10:00PM +0100

On 08/04/2021 21:52, Paavo Helde wrote:
 
> Sorry, my bad. Here is a corrected version:
 
>     long long x;
 
 
Change that line to:
 
string x;
 
Then your program will return the correct results.
 
You need to master the variables and their limits.
Real Troll <real.troll@trolls.com>: Apr 08 10:15PM +0100

On 08/04/2021 21:52, Paavo Helde wrote:
 
> Sorry, my bad. Here is a corrected version:
 
 
You can also use this example if you want to stick with numbers:
 
#include <iostream>
#include <string>
#include <sstream>
#include <iomanip>
 
using namespace std;
 
int main() {
const char* buffer =
"123456789012345678912345678901234567891234567890123456789";
double x;
istringstream is(buffer);
is >> x;
cout << setprecision(80);
cout << "istream produced: " << x << "\n";
return 0;
}
Paavo Helde <myfirstname@osa.pri.ee>: Apr 09 12:35AM +0300

09.04.2021 00:00 Real Troll kirjutas:
 
> Change that line to:
 
> string x;
 
> Then your program will return the correct results.
 
Sure, but Juha was keen to have a choice to get uncorrect results, how
could I possibly disappoint him now?
Rud1ger Sch1erz <nospam_tigre@yahoo.es>: Apr 08 11:44PM +0200


> You need to master the variables and their limits.
 
Same applies to scanf (just saying).
 
(While I didn't miss scanf the last 30 years or so...)
 
--
Tschau
Rüdiger
Real Troll <real.troll@trolls.com>: Apr 08 10:45PM +0100

On 08/04/2021 22:35, Paavo Helde wrote:
 
> Sure, but Juha was keen to have a choice to get uncorrect results, how
> could I possibly disappoint him now?
 
 
I don't normally spend time trying to find incorrect results; I just
use what is already in the standard libraries of the programming languages.
 
I find it less interesting when intelligent people like Bonita, Bart
and others try to write their own functions and compilers when C++, C
and C# have already got most of them that works out of the box. Some
other features are developed by Boost <https://www.boost.org/> and
people can also use them.
Real Troll <real.troll@trolls.com>: Apr 08 11:00PM +0100

On 08/04/2021 22:44, Rud1ger Sch1erz wrote:
> Same applies to scanf (just saying).
 
> (While I didn't miss scanf the last 30 years or so...)
 
In Visual Studio you can use sscanf() like so:
 
Juha Nieminen <nospam@thanks.invalid>: Apr 08 05:35PM

> Correct. IEEE-defined floating point operations are definitely not
> associative - I don't think they are even always commutative, but I
> could be wrong there (I am no expert in this area).
 
IIRC strict IEEE compliance requires for summation and multiplication
to be commutative (ie. always give bit-by-bit the exact same result),
but don't quote me on that.
F Russell <fr@random.info>: Apr 08 08:51PM

On Thu, 08 Apr 2021 08:01:06 -0400, Richard Damon wrote:
 
 
> Double Precision floating point numbers represent only slightly less
> than 2**64 discrete values.
 
That's not true.
 
An IEEE standard double has a 54 bit mantissa (53 + 1 normalized bit)
and therefore there are 2^54-1 numbers per exponent value.
 
The "per exponent value" is important.
 
As the exponent value increases the density of doubles per binary
"decade" decreases.
 
IOW, for larger and larger values, the density of exactly representable
numbers decreases. There are more and more "gaps" per binary "decade."
 
But we can always go to higher precision FP in software.
 
Why was the 64-bit hardware FP chosen?
 
William Kahan, the father of the IEEE-854 standard, said that 64-bits
were chosen so that the average programmer would not have to hire
an expensive error analyst to ensure that his code was correct.
 
But error analysis is mandatory for all critical FP computation.
Bart <bc@freeuk.com>: Apr 08 10:07PM +0100

On 08/04/2021 21:51, F Russell wrote:
 
> That's not true.
 
> An IEEE standard double has a 54 bit mantissa (53 + 1 normalized bit)
> and therefore there are 2^54-1 numbers per exponent value.
 
The mantissa is 53 bits including an implicit bit.
 
2**54 numbers times approx 2**11 exponent values, and adding in the sign
bit, would come to 2**66 different values representable in 64 bits?
 
64 bits clearly can represent 2**64 different values, but many will be
invalid floating point numbers (loads of NaNs for example).
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 08 02:55PM -0700

>> Double Precision floating point numbers represent only slightly less
>> than 2**64 discrete values.
 
> That's not true.
 
How exactly is it not true?
 
> "decade" decreases.
 
> IOW, for larger and larger values, the density of exactly representable
> numbers decreases. There are more and more "gaps" per binary "decade."
 
All that is correct -- but how does it refute the original statement?
 
There are clearly 2**64 representations for 64-bit double-precision
floating-point. My understanding is that most of those represent unique
real values, which implies that
 
Double Precision floating point numbers represent only slightly less
than 2**64 discrete values.
 
So where is the incorrect statement? (If you're quibbling about the
meaning of "discrete", perhaps "distinct" would have been clearer.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 08 12:20PM -0400

On Thu, 8 Apr 2021 17:02:01 +0100
> On 08/04/2021 01:33, Rick C. Hodgin wrote:
> > Stop being divisive. We are stronger together than we are apart.
> I wouldn't work with you if someone paid me 1 million USD to.
 
I would work with you because you are valuable, smart, capable, and your
insight would prove valuable if you ever stepped down from your
framework of hating all things of God.
 
God created this entire solar system to create Earths that take 100s of
thousands of years each to produce, and He didn't do it for the Earth's
sake. He did it for *YOUR* sake, Leigh. God loves you, and He's trying
to teach you something. Trying to undo the false teachings of the
enemy.
 
Your whole world is crumbling by this theory. It's no wonder you're
lashing out. But try to get past that outrage and seek the truth. It
will lead you to the correct place, and give you peace of mind and
security.
 
--
Rick C. Hodgin
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)