- Tricky ... - 1 Update
- contradiction about the INFINITY macro - 1 Update
- I think references should have been const by default - 7 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 28 01:49PM -0700 On 10/10/2021 10:21 PM, Branimir Maksimovic wrote: >> https://www.youtube.com/watch?v=2gznap7wLeQ > Nice work of art, show me more ! > Thanks! Fwiw, Here is a new, highly experimental animation of one of my biomorphic fractal algorithms using rings comprised of tori. Next version will have some music! ;^) Well, what do you think? https://youtu.be/3abgNkpIY98 https://www.youtube.com/watch?v=3abgNkpIY98 |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 28 11:22AM -0400 On 10/28/21 5:38 AM, Vincent Lefevre wrote: >> perfectly clear what that description means when overflow occurs. > Why "perfectly clear"??? This is even inconsistent with 7.12.1p5 > of N2596, which says: 7.12.1p5 describes the math library, not the handling of floating point constants. While the C standard does recommended that "The translation-time conversion of floating constants should match the execution-time conversion of character strings by library functions, such as strtod , given matching inputs suitable for both conversions, the same result format, and default execution-time rounding." (6.4.4.2p11), it does not actually require such a match. Therefore, if there is any inconsistency it would not be problematic. > of the mathematical result is finite but so large that the > mathematical result cannot be represented without extraordinary > roundoff error in an object of the specified type. 7.12.1p5 goes on to say that "If a floating result overflows and default rounding is in effect, then the function returns the value of the macro HUGE_VAL ...". As cited above, the standard recommends, but does not require, the use of default execution-time rounding mode for floating point constants. HUGE_VAL is only required to be positive (7.12p6) - it could be as small as DBL_MIN. However, on implementations that support infinities, it is allowed to be a positive infinity (footnote 245), and when __STDC_IEC_559__ is pre#defined by the implementation, it's required to be positive infinity (F10p2). Even if it isn't positive infinity, it is allowed to be DBL_MAX. DBL_MAX and positive infinity are two of the three options allowed by 6.4.4.2p4 for constants larger than DBL_MAX, in which case there's no conflict. If HUGE_VAL is not one of those three values, then 6.4.4.2p4 still applies, but 7.12.1p5 need not apply, since a match to the behavior of strtod() is only recommended, not required.. > DBL_MAX and that rounds to DBL_MAX (e.g. with round-toward-zero), > there should be an overflow, despite the fact that the FP result > is not greater than DBL_MAX (since it is equal to DBL_MAX). Agreed. As a result, the overflow exception should be signaled. However, the C standard mandates that "Floating constants are converted to internal format as if at translation-time. The conversion of a floating constant shall not raise an exceptional condition or a floating-point exception at execution time." (6.4.4.2p8). If an implementation chooses to do the conversion at translation-time, the exception would be raised only within the compiler, which has no obligation to do anything with it. The implementation could generate a diagnostic, but such a constant is not, in itself, justification for rejecting the program. Therefore, if an implementation chooses to defer actual conversion until run-time, it's required to produce the same results, which means it must clear that overflow exception before turning control over to the user code. > Moreover, with the above definition, it is DBL_NORM_MAX that is > more likely taken into account, not DBL_MAX. According to 5.2.4.2.2p19, DBL_MAX is the maximum representable finite floating point value, while DBL_NORM_MAX is the maximum normalized number. 6.4.4.2p4 refers only to representable values, saying nothing about normalization. Neither 7.12.5p1 nor 7.12p6 say anything to require that the value be normalized. Therefore, as far as I can see, DBL_MAX is the relevant value. > obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules > (where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX, > despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf). Yes, and DBL_MAX and +Inf are two of the three values permitted by 6.4.4.2p4, so I don't see any conflict there. As far as I can see, the value required by IEEE 754 is always one of the three values permitted by 6.4.4.2p4, so there's never a conflict. Are you aware of any? For hexadecimal floating point constants on systems with FLT_RADIX a power of 2, 6.4.4.2p4 only allows one value - the one that is correctly rounded - but that's precisely the same value that IEEE 754 requires. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 05:17AM >>No, it doesn't. It declares a pointer. What do you think this will print? > Which parts of "syntax" and "under the hood" is confusing you. Perhaps in your > own language? And which part of "an array and a pointer are different things" do you not understand? The function is *not* taking an array. It's taking a pointer. This is not just "it's taking a pointer under the hood". It's taking a pointer with respect to C syntax. Just because there are several alternative syntaxes to specify the type of pointer doesn't matter. It's still a pointer. Not just in its underlying representation, but at the language syntax level. These three declarations are identical and mean the same thing, they are merely using alternative syntaxes to express the same thing: void foo(int *ptr) {} void foo(int ptr[]) {} void foo(int ptr[10]) {} C++ supports function overloading. However, if you try to do the above in C++ you'll get redefinition errors, because all three are identical. Contrast that with, for example: void foo(int *ptr) {} void foo(int &ptr) {} Those two might result in identical binaries under the hood, but they are syntactically different, and will not cause a redefinition error. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 05:20AM > { > a[10][50] = 123; > } If 'a' there is an array, what will sizeof(a) be? > int main() > { > int a[2][3]; Contrast that to what sizeof(a) will be here. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 27 11:10PM -0700 On 10/27/2021 10:20 PM, Juha Nieminen wrote: >> a[10][50] = 123; >> } > If 'a' there is an array, what will sizeof(a) be? It can be equal to sizeof(void*)... |
| JohnnyCameLater@whatsthetime.net: Oct 28 09:29AM On Wed, 27 Oct 2021 17:21:34 +0100 >>>in this context, what [] means is pointer semantics. >> Oh really? >Yes. No. >> 1 warning generated. >> Nuff said. >Not really. Note that the compiler does not complain about the first Yes really. The parser is treating it as an array and doing bounds checking. The fact it gets implicitely converted into a pointer later is irrelevant. >index (10) being out of bounds. That's because (despite the badly So what? Clang compilation generally stops at the first error it finds. >x.c:6:18: note: while referencing 'a' > 6 | void func2(int (*a)[3]) > | ~~~~~~^~~~~ Thank you for proving my point that the gcc parser also treats it as an array. |
| JohnnyCameLater@whatsthetime.net: Oct 28 09:30AM On Thu, 28 Oct 2021 05:17:54 -0000 (UTC) >> own language? >And which part of "an array and a pointer are different things" do you not >understand? Ok, you're either just plain thick or you're trolling now. |
| JohnnyCameLater@whatsthetime.net: Oct 28 09:30AM On Thu, 28 Oct 2021 05:20:52 -0000 (UTC) >> { >> int a[2][3]; >Contrast that to what sizeof(a) will be here. FFS man, do you even understand whats being discussed here? |
| Bart <bc@freeuk.com>: Oct 28 11:20AM +0100 > The fact it gets implicitely converted into a pointer later is irrelevant. >> index (10) being out of bounds. That's because (despite the badly > So what? Clang compilation generally stops at the first error it finds. (Does it?) >> 6 | void func2(int (*a)[3]) >> | ~~~~~~^~~~~ > Thank you for proving my point that the gcc parser also treats it as an array. In: void func(int a[2][3]) ... the type of 'a' is: 'pointer to array 3 of int'. For parameters, the first level of a type starting T[] is reduced to T*, a pointer: T[][] becomes T(*)[]. So arrays exist in the lower dimensions, but never in the primary one, which is where it would be necessary for arrays to be passed by value. But apart from that quibble, you're spot on. I can see now that you were pretty much right about everything, and all the long-standing experts here have no idea what they're talking about. |
| 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