3 ms·

I'm not a c programmer, but having unit tests automatically run at compile time seems odd. If i wanted to run tests at the same time as compiling i would put th

• zeroonetwothree 2y ago
  Why is it odd? The compiler does all sorts of other checks based on things like static assert or type information.
  • kstenerud 2y ago
    It's odd because you lose control over that aspect of compilation. It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore. That would be even more annoying than Go's stupidly pedantic compiler.
    • Alifatisk 2y ago
      > It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Can't that be an optional thing decided by some compiler flag? I think I remember doing something like that in D.
      • kstenerud 2y ago
        That's how one would normally do it, and that's what I would expect to see: Build for development, and the compiler only errors out if things are so bad that it's unable emit a binary (for everything else, it emits warnings). Build for release, and it errors out unless EVERYTHING is done right. Unfortunately, ever since golang decided on an autocratic and backwards "there are no warnings, only errors" policy, others have started to sip from the same kool aid jar.
• sixthDot 2y ago
  Most of D users would rather call that "static contracts". I dont know why the author choose to call that "unit test".