Skip to main content
11 events
when toggle format what by license comment
May 13, 2024 at 20:27 vote accept Madagascar
May 10, 2024 at 19:13 comment added indi I don’t really use header-only libraries, and particularly not for testing. But Catch2 is fine. Boost.Test is what I usually use, and works as header-only. There’s also μt, doctest, and many more. Even GoogleTest would work if you must. Really, any testing library is fine. One can quibble over which one is better, but most are basically the same for simple purposes, and in any case, even the worst testing library ever made is infinitely better than no testing library at all. So… it doesn’t really matter which you pick.
May 10, 2024 at 10:37 comment added Madagascar @indi Okay, is there any simple header-only testing only you'd suggest? Perhaps Catch2?
May 9, 2024 at 18:33 comment added ilkkachu @Harith, the thing about globals is that they're bad if you ever extend the code so that you might need more than one instance if the value. In general, it's mostly a good idea to consider that beforehand, rather than taking the risk of needing extensive overhauls over the code base later. But you can take into consideration how likely that is going to be. And if your goal is to implement the set of standard shell utilities (a rather fixed set), the chances of needing to overhaul wc into a reusable library function are pretty close to nil.
May 9, 2024 at 9:59 comment added indi @ilkkachu “Running the program to see if it gives the proper output” is not testing the function (unit testing), it is (at best, if done systematically, which, frankly, it won’t be) testing the program (integration testing). So the function remains untested. That’s basically not testing at all. And, yes, you would test the function by checking that it outputs a message, and maybe do some tests on the form of the message… all while also running your various sanitizers to make sure nothing else suspicious is going on. “Testing” is not just running the code and saying “eh, looks okay ¯_ (ツ)_/¯”.
May 9, 2024 at 9:57 comment added indi @Harith Trailing return syntax has been around since C++11, and was added because of numerous shortcomings with the old style. Since trailing return is required in some cases, I don’t see the point in mixing styles. I just always use trailing return, dropping the trailing part if it’s not necessary, when the return type can be deducted (which is very often).
May 9, 2024 at 9:57 comment added indi @Harith C code, including the code of many classic shell utilities, tends to be very low quality. It is rarely tested, and there’s often not even any error checking (few C coders even know that functions like printf() return error codes). It’s also often poorly designed, because doing things well requires complexity that C is ill-equipped to handle. I wouldn’t take software engineering cues from most C code.
May 9, 2024 at 7:44 comment added ilkkachu TBH, the command line options do have rather a global significance for a tool like this, and it's not like the code is untestable, as you can still run the program to see if it gives the proper output. And, seriously, what would you test with a function that just prints an error message? Would you duplicate the message in the test suite to check that the function gives the correct output..?
May 8, 2024 at 20:44 comment added Madagascar auto main(int argc, char* argv[]) -> int ==> I didn't know Python's syntax had made its way into C++. How's this better than int main(...)?
May 8, 2024 at 20:38 comment added Madagascar I originally had a struct with the flags and had everything local, but then I looked at my previous reviews for shell utilities (C, not C++) and read the source code of some GNU coreutils, and made everything global. :)
May 8, 2024 at 20:31 history answered indi CC BY-SA 4.0