bizarre bug
I was making changes to squad membership updating and tactical targeting, which happens once every 8 frames. And I hit a bug which had these symptoms: Steamhammer appeared to run normally, but extremely slowly. Each frame took a second or more. Not each eighth frame, each single frame. Also Steamhammer was unable to recognize its slowness; its timer said that the mean frame took 0.1 milliseconds, normal for the very early game which was as far as I let it run. What could cause such bizarre behavior?
It took a long time to debug. I finally traced it to a misplaced } character which included too much in an if, with the result that an important value was never initialized. It was not easy to see in the code. How this caused a slowdown and how the slowdown stayed outside the timed code (or otherwise broke the timer's behavior) I do not know, and don't expect to find out....
It is worth it to use a prickly language like C++? One wrong touch and you get glochids in your skin for who knows how long. Some days I think about recoding Steamhammer in a pleasant language like Haskell, where new code more often than not works the first time. But that also comes with big disadvantages.
Trackbacks
No Trackbacks
Comments
Nininene on :
McRave on :
Jay Scott on :
Marian on :
On the other hand you get more power and freedom.
Also I am a big fan of const-correctness.
Stanislaw Halik on :
I wonder how much time you'd save using Haskell (or ML), a modern language, compared to the C++ standard you're using now. One thing I'm sure you'd chain lots of stuff together using random infix operators. To each his own I guess.
C++17 is a decent language and Microsoft compilers now support it. It's not the "old C++" that made me a C89 holdout. Interestingly, C++11 and above supports higher-kinded types (in fact, variadic "infinite" kinds). I do much work using template partial specialization that's sort-of-equivalent to class/instance in Haskell.
Jay Scott on :
Stanislaw Halik on :
int foo;
Bar bar { ... foo, ... };
-- where `int foo' is initialized in the constructor.
Using C++11 and above I've had no need in my own code to use bare pointers and explicit "delete". I've only had few cases needing Valgrind, and no cases needing asan or ubsan.
Finally, Visual Studio now supports the _full_ C++17 standard, no exceptions. You can write portable code for this standard across all supported platforms with no need for mingw-w64. MSVC++ has a better linker for PE/COFF targets sadly.