I write all my C and C++ code at warning level 4 (the maximum, which is probably equivalent to -Wall). IMO, it was a mistake for Visual Studio to default to warning level 3. Ignoring the compiler in production code is a sign of laziness, or that you don't take what you're doing seriously.

Warnings should be disabled on a per-source-file basis. And since you actively choose to ignore specific warnings, you still benefit from the compiler's other sanity checks.

In Visual Studio, this is accomplished by

  #pragma warning( disable: 4100 )

at the top of a .c or .cpp file. This will ignore "unreferenced parameter" warnings. (Personally, I don't ignore those either. It's saved me on more than one occasion, and once is enough for me. So instead, I use a macro UNREF_PARAM(param) to suppress the warning in specific cases.)

A header file sometimes generates a warning that you want to choose to ignore. But if we disabled it in the header file, then that disable would propagate to all other code which included the header file -- a big mistake!

Visual Studio solves this by:

  #pragma warning( push )
  #pragma warning( disable: 4100 )
  //----------------------------------------------------
  // foo.h
  //   The Foo module serves as an example of how to
  // properly suppress the "unreferenced parameter"
  // warning within a header file, via Visual Studio's
  // #pragma warning( push ) and pop mechanism.
  //----------------------------------------------------
  /*
    .... code which generates the warning ....
  */
  #pragma warning( pop )

This allows you to "scope" the disable to a single header file.

(Lastly, it's worth noting that SQLite outputs hundreds of warnings --- but they are neither lazy nor irresponsible, because they have hundreds of unit tests to verify that SQLite works correctly at runtime, as defined by the tests, across all platforms.)