- "All C++20 core language features with examples" by Oleksandr Koval - 1 Update
- Response video to Anton Petrov 0037 - 1 Update
- maybe a stupid question - 6 Updates
- #include'ing .c files considered harmful? - 1 Update
- What's the correct fmod()-algorithm - 1 Update
| Cholo Lennon <chololennon@hotmail.com>: Apr 09 01:14PM -0300 On 4/8/21 7:50 PM, Lynn McGuire wrote: > 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. Very useful, thanks :-) -- Cholo Lennon Bs.As. ARG |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Apr 09 04:19PM +0100 On 08/04/2021 17:20, Rick C. Hodgin wrote: > 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. Take your meds. /Flibble -- 😎 |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 08 10:34PM -0400 On 4/8/21 2:14 AM, Juha Nieminen wrote: >> Note that scanf has undefined behavior on numeric input if the value >> can't be represented in the target type. > What's the better alternative in standard C++? The C++ routines for doing numeric conversions described in section 21.3.4 have well-defined behavior in such situations - they throw an exception that can be caught, if desired. The std::num_get::do_get() function also have well-defined behavior when performing such conversions, namely assigning ios_base::failbit to err. (28.4.2.1.2). Either of those is preferable to undefined behavior. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 08 11:22PM -0700 > Is there some reason you need to use scanf? > Note that scanf has undefined behavior on numeric input if the > value can't be represented in the target type. [...] The possibility of undefined behavior is easily avoided in most cases, and certainly in this case, simply by using a maximum field width as part of each conversion specifier: int day, month, year; int items; ... items = sscanf( input, "%2d.%2d.%4d", &day, &month, &year ); if( items == 3 ) ... etc ... The given field widths guarantee the input values can be represented in the respective target types, even if int is only 16 bits. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 08 11:30PM -0700 > are experienced about scanf than there are here. > In fact you can see that all replies about scanf are from regular > posters in comp.lang.c. There may be more potential responders in comp.lang.c, but the best ones also read comp.lang.c++. So asking here is likely to give a higher average quality of answer. :) Only half tongue-in-cheek... |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 08 11:38PM -0700 > As scanf() can invoke UB (read: incorrect results) very easily if > the input stream does not match the expected results, it is > unusable with any external content (i.e. basically always). [...] Nonsense. The undefined behavior you refer to can always be avoided by using an appropriate maximum field width in each conversion specifier. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 09 12:29AM -0700 > Nonsense. The undefined behavior you refer to can always be > avoided by using an appropriate maximum field width in each > conversion specifier. Not always (though as you said it can be in the case that started this thread). For example, if you're reading a 16-bit integer, limiting the field width means you can't read values over 9999 -- or, if I'm not mistaken, values less than -999 for a 16-bit signed integer. -- 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 */ |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 09 11:30AM +0200 On 08.04.2021 20:41, Paavo Helde wrote: > 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): The design of EOF handling in iostreams is practically incompatible with exception throwing mode. I guess that's a main reason why nobody uses that mode. It's just totally impractical, due to the iostreams design. > } > Output: > istream produced: 2147483647 - Alf |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 08 11:55PM -0700 >> Memory does not have a type. Objects have a type, but memory >> does not have a type. > A bit pedantic, perhaps. Not at all. > reordable/nonreorderable, early-return/non-early return semantics. > Some programers need pay close attention to the memory type, even when > using C++. These comments have nothing to do with what I was talking about. |
| Richard Damon <Richard@Damon-Family.org>: Apr 08 09:29PM -0400 On 4/8/21 4:51 PM, F Russell wrote: > 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. My memory is that IEEE 64 bits has: 1 Sign Bit 11 Exponent Bits 52 Mantissa Bits For exponents other than 0, the 52 bits have an assumed leading 1, but there are still only 2**52 values per exponent value (not -1 as all 2**52 are valid values) The 11 Exponent bits give 2048 possible values, The highest is for NaNs and Inf, but the rest are values (0 are denormals, but there are still 2**52 of those), and we have 2 values for each of those (except for 0, sort-of) so we actually have: 2 * (2**11-1) * 2**52 -1 distinct (finite) values that can be represented. This is just slightly less that 2**64 distinct values. The exact value is 2**64 - 2**53 - 1 64 bits is big enough, that as long as you avoid the case of subtracting two almost equal numbers, most calculations will just be good enough. The trick is to watch your math to make sure that you never get that form of cancellation occuring. |
| 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. |
No comments:
Post a Comment