Is this Regular Expression for UTF-8 Correct??
in [MFC]
|
From: Peter Olcott on 28 May 2010 09:05 On 5/27/2010 11:40 PM, Liviu wrote: > "Pete Delgado"<Peter.Delgado(a)NoSpam.com> wrote... >>>> >>>> Again, removing the context of the wager, the claim that you will >>>> have written code with specific performance characteristics, won't >>>> work here. Anyone can view the thread to see what you have done. >> >> BTW: I noticed that you posted some code and at least had the decency >> to cite the original source! rotfl... that hardly qualifies as >> *original work*, but then at this point I suppose that I should be >> happy that you posted anything at all! > > Heh... I believe the original part can be reduced to > > int main() { > return 0; > } > > since the rest would be discarded by any half-decent compiler/linker > in an optimizing mood. If Peter cared to profile that at all, it would > score sky high performance, for sure. Take that, you naysayers ;-) > > Liviu > > http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ I would guess that the above code might be about twice as fast as my code specifically because of the overhead of a switch statement. I still like my code better for the single reason that it is much easier to understand. I really like the above code too. It is very well written. I have found that maximum readability also directly leads to maximum reliability and minimum debugging. In the case where a function can be easily exhaustively tested, is reasonably easy to read, and probably won't need to be modified the increase of readability over speed is not as important. In this case speed may outweigh readability. http://www.ocr4screen.com/UTF8.cpp If his code is any faster at all than mine this would disprove Joe's statement that you can't known anything at all about performance without actual testing. Of course Joe's statement was such an over exaggeration that it would be easy to disprove.
From: Oliver Regenfelder on 28 May 2010 09:25 Hello, Peter Olcott wrote: > I have found that maximum readability also directly leads to maximum > reliability and minimum debugging. There is at least one bug in your code which can be spotted when reading it and complete prevents your example from working. And a switch with goto where a loop would suffice does not count as readable for me. Best regards, Oliver
From: Peter Olcott on 28 May 2010 10:21 On 5/28/2010 8:25 AM, Oliver Regenfelder wrote: > Hello, > > Peter Olcott wrote: >> I have found that maximum readability also directly leads to maximum >> reliability and minimum debugging. > > There is at least one bug in your code which can be spotted when reading > it and complete prevents your example from working. > > And a switch with goto where a loop would suffice does not count as > readable for me. > > Best regards, > > Oliver I only use gotos in place of break statements within switch statements in time critical code. I never use gotos anywhere else. If you don't use a goto in place of the break; statement then two rather than one assembly language jumps are generated. The break causes the code to jump to the bottom, where the loop has it jump back to the top. Maybe optimizers are smart enough to avoid this now.
From: Peter Olcott on 28 May 2010 10:53 On 5/28/2010 9:21 AM, Peter Olcott wrote: > On 5/28/2010 8:25 AM, Oliver Regenfelder wrote: >> Hello, >> >> Peter Olcott wrote: >>> I have found that maximum readability also directly leads to maximum >>> reliability and minimum debugging. >> >> There is at least one bug in your code which can be spotted when reading >> it and complete prevents your example from working. >> >> And a switch with goto where a loop would suffice does not count as >> readable for me. >> >> Best regards, >> >> Oliver > > I only use gotos in place of break statements within switch statements > in time critical code. I never use gotos anywhere else. > > If you don't use a goto in place of the break; statement then two rather > than one assembly language jumps are generated. The break causes the > code to jump to the bottom, where the loop has it jump back to the top. > Maybe optimizers are smart enough to avoid this now. This very limited use of the goto does not really add to complexity at all. The break statement that the gotos replaced is essentially a goto that jumps to the bottom. All that I did was change the direction of this pre-existing goto to always jump to the top rather than always jump to the bottom.
From: Liviu on 28 May 2010 12:22
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... > > I have found that maximum readability also directly leads to maximum > reliability and minimum debugging. In the case where a function can be > easily exhaustively tested, is reasonably easy to read, and probably > won't need to be modified the increase of readability over speed is > not as important. In this case speed may outweigh readability. > > http://www.ocr4screen.com/UTF8.cpp Compared to the first revision you posted yesterday, this one at least fixes the infinite loops. That alone is a major speedup, indeed ;-) Now maybe if you tried to actually test it, you'd find the next obvious error, painfully obvious to anyone even remotely fluent in C/C++. Which is even more odd since I thought you were writing code so perfectly designed that it needed virtually no debugging. Liviu |