1. 4

Just a helpful little trick I’ve picked up that others may find useful. It’s not super complicated, but it’s a great way of shutting up a kvetching compiler.

  1.  

  2. 2

    In C, I just write:

    (void)foo;
    

    Readers who know this idiom will understand the code without having to look up a macro definition, and to those who don’t the macro will not help, unless named verbosely.

    The Go variant is:

    _ = foo;
    
    1. [Comment removed by author]

      1. 1

        I agree with Go authors' sentiment that if it’s worth warning about, it’s worth erroring on, because people don’t tend to read warnings that scroll by during compilation or care about them. It’s also hard to distinguish between warnings that you know are nothing to worry about and others. For these reasons I always add -Werror (among other -Ws) to CFLAGS in my Makefiles.

        1. [Comment removed by author]

          1. 2

            I prefer constant vigilance to hack-then-fix. A matter of taste, perhaps; I can’t really argue that your view is wrong.

    2. 1

      Is the typo of “function” as “fucntion” in the article on purpose?

      1. 2

        No, I’m just a moron who doesn’t spellcheck things.

        EDIT: Fixed. Zarrow boogs!

      2. 1

        I can’t recall the last time this warning ever revealed anything interesting. I just turn it off instead of cluttering code with more noise. And then you get warnings about statement has no effect, which is a useful warning.

        1. 1

          You can also omit or comment out unused parameter names in C++. It has the same effect.

          void foo( int /*bar*/ ) {  
             return;  
          }.