| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 11 12:30AM +0100 I finally found a use for the `continue` statement, after some 25+ years of C++. Also, learned that (apparently, but haven't really tested) `std::optional` seems to be `constexpr`-compatible. Code: inline constexpr auto operator""_u128( const C_str spec ) -> Uint_128 { const char apostrophe = '\''; // TODO: use common exception handling. Uint_128 result = 0; for( int i = 0; spec[i] != '\0'; ++i ) { const char ch = spec[i]; if( ch != apostrophe ) { if( not( '0' <= ch and ch <= '9' ) ) { throw runtime_error( "Invalid character '"s << ch << "' in _u128 literal." ); } optional<Uint_128> shifted = mul( 10, result ); if( shifted.has_value() ) { const Uint_128 new_result = shifted.value() + (ch - '0'); if( new_result >= result ) { result = new_result; continue; } } throw runtime_error( "Uint_128 value range exceeded for _u128 literal." ); } } return result; } However, it would be a little strange if indeed I had found a case where there is no arguably better alternative than using `continue`. So, mainly because I don't see it, is there a better way to do that failure handling, preferably without repeating oneself? - Alf |
| MrSpook_s_x285@tmpo953x94x_dv5i2w.ac.uk: Mar 11 09:14AM On Thu, 11 Mar 2021 00:30:01 +0100 >However, it would be a little strange if indeed I had found a case where >there is no arguably better alternative than using `continue`. You've demonstrated many times that your style of coding is overcomplicated gibberish so no surprise you don't like a simple construct such as continue; |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 11 11:53PM +0200 11.03.2021 01:30 Alf P. Steinbach kirjutas: > I finally found a use for the `continue` statement, after some 25+ years > of C++. Good for you. There is nothing wrong with using 'continue' when it fits the task. But if you want to make your code better, then with your example it's simple. You have just move the overflow exception throwing inside the Uint_128 * and + operators. This would have the side benefit of getting rid of those optional values, there is no point in dragging zombies along if you are just throwing an exception whenever one appears. The final code might then look something like that: inline constexpr Uint_128 operator""_u128( const char* spec) { Uint_128 result = 0; for (int i = 0; spec[i]; ++i ) { const char ch = spec[i]; if (ch == '\'') { continue; } if (ch<'0' || ch>'9') { throw runtime_error( "Invalid character '"s << ch << "' in _u128 literal." ); } // this will throw inside on overflow result = result*10 + (ch - '0'); } return result; } |
| red floyd <myob@its.invalid>: Mar 11 02:01PM -0800 On 3/11/2021 1:53 PM, Paavo Helde wrote: > } > return result; > } Or, to keep Alf's head from exploding because of the continue... inline constexpr Uint_128 operator""_u128( const char* spec) { Uint_128 result = 0; for (int i = 0; spec[i]; ++i ) { const char ch = spec[i]; if (ch != '\'') { if (ch<'0' || ch>'9') { throw runtime_error( "Invalid character '"s << ch << "' in _u128 literal." ); } // this will throw inside on overflow result = result*10 + (ch - '0'); } } return result; } |
| olcott <NoOne@NoWhere.com>: Mar 11 03:15PM -0600 On 3/11/2021 2:52 PM, Kaz Kylheku wrote: > You don't recognize that wildly different pieces of code at different > addresses in the image could all be equivalent to Halts, and that H_Hat > could use any of those instead of Halts. You seem to keep forgetting that I am not defining a universal halt decider. There is no finite limit to the inputs that a universal halt decider would be required to decide. All that I am doing is showing how exactly once instance of the halting problem counter-examples that have been used to prove undecidability is actually decidable. The whole: "do the opposite of whatever the halt decider decides" Does not prove the undecidability of the halting problem, thus refuting all the proofs that depend on it: Now we construct a new Turing machine D with H as a subroutine. This new TM calls H to determine what M does when the input to M is its own description <M>. Once D has determined this information, it does the opposite. That is, it rejects if M accepts and accepts if M does not accept. (Sipser 1997:165) http://www.liarparadox.org/sipser_165.pdf Sipser, Michael 1997. Introduction to the Theory of Computation. Boston: PWS Publishing Company (165-167) > "invoke something at a specific address" but "invoke the abstract > algorithm Halts(P, P)". That calculation can be embodied in an > infinite variety of ways which calculate the same thing. As mathematical functions key details are simply abstracted away which is essentially the same thing as pretending that these details do not exist. When the counter-example to the halting problem is defined as an actual computation these key details are mandatory and cannot simply be assumed away. When these key details are not simply assumed away they provide the basis of decidability. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| 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