- cannot find C++ regex tester - 1 Update
- Finally found a use for the `continue` statement. - 4 Updates
- [TEST] Sorry Google Groups Problems - 1 Update
| lew pitcher <toodlelew@gmail.com>: Mar 12 07:49AM -0800 On Saturday, September 12, 2020 at 2:39:51 AM UTC-4, RM wrote: > Finally I programmed a solution without regex. > Problem closed. I know that I'm late to this party, but ... do you care to share your solution? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 12 01:07AM +0100 On 11.03.2021 23:01, red floyd wrote: > } > return result; > } Thanks for these attempts. There are some costs: * The overflow exception message no longer mentions a literal. * The arithmetic operations no longer wrap, as usual for unsigned type. For a compile time exception both Visual C++ and MinGW g++ report the origin as the literal expression itself, so that's OK anyway. I guess with some other compiler that reported only the expression throwing site, moving the throwing down into arithmetic operations could create a little mystery when this happens. But I don't know such compiler. Perhaps there are good workarounds for the exception message? However, I see no practical way to deal with the throwing arithmetic operations for an unsigned type. Special named throwing arithmetic operations could be defined for this and similar uses. But thinking about that my head feels like exploding. :( Cheers, - Alf |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 12 12:42PM +0200 12.03.2021 00:01 red floyd kirjutas: > } > return result; > } This increases the indentation of function's main logic by 1 level, which is a bad thing in my book. Anyway, I do not like any of the shown variants very much, they remind me C style too much (or for Alf's variant, Pascal) where 95% of code is dedicated for error checking and handling. In C++ we can have main logic clear and visible, with error checking still there, but not taking the most prominent place. Maybe something like that (you can see I still prefer 'continue;' over an extra indentation level in main logic): inline constexpr Uint_128 operator""_u128( const char* spec) { Uint_128 result = 0; for (int i = 0; spec[i]; ++i ) { if (Preprocess(spec[i])) { continue; } // actual work result = result*10 + (spec[i] - '0'); } return result; } // Range checking, error handling, and trivial preprocessing // tucked away from the main logic. inline constexpr bool Preprocess(char ch) { if (ch == '\'') { // processed fully return true; } if (ch<'0' || ch>'9') { throw runtime_error( "Invalid character '"s << ch << "' in _u128 literal." ); } // not processed return false; } |
| Bo Persson <bo@bo-persson.se>: Mar 12 12:17PM +0100 On 2021-03-12 at 11:42, Paavo Helde wrote: > } > return result; > } But *how* bad is an extra indent (for an else-part), compared to a head-exploding continue? :-) Almost every use of continue in if (condition) continue; normal_processing; can of course be written as if (!condition) normal_processing; And very often you can make this even more readable by chosing "condition" properly, so that the negation in the if-statement can be avoided. Bo Persson |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 12 03:42PM +0200 12.03.2021 13:17 Bo Persson kirjutas: >> } > But *how* bad is an extra indent (for an else-part), compared to a > head-exploding continue? :-) In this very simple example where "normal processing" is one line, not very bad. But in my experience, the "normal processing" block is often much more complicated than 1 line and will contain its own control structures, and every bit of help to keep it simpler is welcome. Also, the software complexity has a tendency to grow exponentially. Let's say there is some minor annoyance which makes the code 25% more complex to understand than needed. Now tack 10 such minor annoyances on top of each other, probably introduced by different developers over years (who were just trying to not ruin any existing functionality), and you end up with an increase of complexity not 50% or 100%, but ca 10 times. There would be little hope any human could understand what the code is now doing, including the original author. Cheers Paavo |
| Anton Shepelev <anton.txt@g{oogle}mail.com>: Mar 12 03:35PM +0300 Frederick Gotham: > if it has been fixed yet. > I've sent this post to comp.lang.c++ but it might end up > in comp.lang.c instead. It did end up in the C group. I recommend that you register with a free Usenet server, such as Eternal September, and start using a real newsreader. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| 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