未使用の変数に関する警告を無音にする方法を教えてください。

クロスプラットフォームアプリケーションがあり、一部の関数では、関数に渡されるすべての値が使用されていません。したがって、未使用の変数があるというGCCからの警告が表示されます。

警告をコーディングする最良の方法は何ですか？

関数の周りの#ifdef？

#ifdef _MSC_VER
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal qrLeft, qreal qrTop, qreal qrWidth, qreal qrHeight)
#else
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal /*qrLeft*/, qreal /*qrTop*/, qreal /*qrWidth*/, qreal /*qrHeight*/)
#endif
{

これは醜いですが、コンパイラーが好む方法のようです。

または、関数の最後で変数にゼロを割り当てますか？（コンパイラの警告を消すためにプログラムフロー内の何かを変更しているため、これは嫌いです）。

正しい方法はありますか？

「」式に入れることができます(void)var;コンパイラーがそれが使用されている（何もしません）。これはコンパイラ間で移植可能です。

例えば

void foo(int param1, int param2)
{
    (void)param2;
    bar(param1);
}

または、

#define UNUSED(expr) do { (void)(expr); } while (0)
...

void foo(int param1, int param2)
{
    UNUSED(param2);
    bar(param1);
}

GCCとClangでは、__attribute__((unused))プリプロセッサディレクティブを使用して目標を達成できます。
例えば：

int foo (__attribute__((unused)) int bar) {
   return 0;
}

C ++ 17が[[maybe_unused]]属性を提供するようになりました。

http://en.cppreference.com/w/cpp/language/attributes

かなりいいと標準。

現在の解決策が最適です。使用しない場合は、パラメータ名をコメント化してください。これはすべてのコンパイラに当てはまるため、GCC専用にプリプロセッサを使用する必要はありません。

C ++ 17アップデート

C ++ 17では、[dcl.attr.unused]でカバーされる属性[[maybe_unused]]を取得します

attribute-token maybe_unusedは、名前またはエンティティーが意図的に未使用であることを示します。これは各属性リストに最大1回出現し、attribute-argument-clauseは存在しません。...

例：

 [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                        [[maybe_unused]] bool thing2) {
  [[maybe_unused]] bool b = thing1 && thing2;
    assert(b);
 }

実装では、NDEBUGが定義されているかどうかにかかわらず、bが未使用であることを警告するべきではありません。—例を終了]

次の例の場合：

int foo ( int bar) {
    bool unused_bool ;
    return 0;
}

clangとgccはどちらも、-Wall -Wextraを使用して、barとunused_boolの両方に対して診断を生成します（ライブでご覧ください）。

[[maybe_unused]]を追加すると、診断が停止します。

int foo ([[maybe_unused]] int bar) {
    [[maybe_unused]] bool unused_bool ;
    return 0;
}

ライブでご覧ください。

C ++ 17より前

C ++ 11では、未使用の変数をキャプチャUNUSEDしたラムダ式（Ben Deaneを介して）を使用して、マクロの代替形式を形成できます。

#define UNUSED(x) [&x]{}()

次の例を考えると、ラムダ式の即時呼び出しは最適化する必要があります。

int foo (int bar) {
    UNUSED(bar) ;
    return 0;
}

godboltで、呼び出しが最適化されていることがわかります。

foo(int):
xorl    %eax, %eax
ret

さらにすっきりとした方法は、変数名をコメント化することです。

int main(int /* argc */, char const** /* argv */) {
  return 0;
}

同僚が私にここでこの素敵な小さなマクロを指摘しました

簡単にするために、以下のマクロを含めます。

#ifdef UNUSED
#elif defined(__GNUC__) 
# define UNUSED(x) UNUSED_ ## x __attribute__((unused)) 
#elif defined(__LCLINT__) 
# define UNUSED(x) /*@unused@*/ x 
#else 
# define UNUSED(x) x 
#endif

void dcc_mon_siginfo_handler(int UNUSED(whatsig))

gccデフォルトではこれらの警告にフラグを立てません。この警告は-Wunused-parameter、コンパイラに渡すことによって明示的に、または渡すことによって暗黙的に-Wall -Wextra（またはフラグの他の組み合わせ）オンになっているはずです。

未使用のパラメーターの警告は-Wno-unused-parameter、コンパイラーに渡すことで簡単に抑制できますが、この無効化フラグは、コンパイラーのコマンドラインでこの警告の有効化フラグの後にある必要があります。

1つまたは複数のパラメーターを未使用として宣言するためのマクロなしの移植可能な方法：

template <typename... Args> inline void unused(Args&&...) {}

int main(int argc, char* argv[])
{
    unused(argc, argv);
    return 0;
}

ほとんどの場合、プリプロセッサディレクティブの使用は悪と見なされます。理想的には害虫のようにそれらを避けたいです。コンパイラにコードを理解させるのは簡単で、他のプログラマがコードを理解できるようにするのははるかに難しいことに注意してください。あちこちでこのような数十のケースがあると、後で自分で読んだり、今すぐ他の人が読んだりすることが非常に難しくなります。

1つの方法は、パラメーターをある種の引数クラスにまとめることです。次に、変数のサブセットのみを使用するか（実際に0を割り当てるのと同じ）、プラットフォームごとにその引数クラスの異なる特殊化を使用できます。ただし、これは価値がないかもしれません。それが適合するかどうかを分析する必要があります。

不可能なテンプレートを読むことができる場合は、「Exceptional C ++」の本に高度なヒントが見つかるかもしれません。あなたのコードを読む人がその本で教えられているクレイジーなものを取り巻くスキルセットを手に入れることができれば、あなたも簡単に読むことができる美しいコードを手に入れるでしょう。コンパイラーは、（前処理によってすべてを非表示にするのではなく）あなたが何をしているかをよく知っています。

まず、警告はヘッダーファイルではなくソースファイルの変数定義によって生成されます。APIドキュメントを生成するためにdoxygenのようなものを使用している可能性があるため、ヘッダーは元の状態を保つことができます。

私はあなたがソースファイルに完全に異なる実装を持っていると仮定します。これらの場合、問題のあるパラメーターをコメント化するか、パラメーターを書き込むことができます。

例：

func(int a, int b)
{
    b;
    foo(a);
}

これは不可解に見えるかもしれないので、UNUSEDのようなマクロを定義しました。MFCの方法は次のとおりです。

#ifdef _DEBUG
#define UNUSED(x)
#else
#define UNUSED(x) x
#endif

このように、デバッグビルドでまだ警告が表示されていると、役立つ場合があります。

パラメータ名を常にコメントアウトするのは安全ではありませんか？そうでない場合は、次のようなことができます

#ifdef _MSC_VER
# define P_(n) n
#else
# define P_(n)
#endif

void ProcessOps::sendToExternalApp(
    QString sAppName, QString sImagePath,
    qreal P_(qrLeft), qreal P_(qrTop), qreal P_(qrWidth), qreal P_(qrHeight))

それは少し醜いです。

私は(void)param2警告を沈黙させる方法の代わりにこれを見ました：

void foo(int param1, int param2)
{
    std::ignore = param2;
    bar(param1);
}

これはC ++ 11で追加されたようです

を使用して UNREFERENCED_PARAMETER(p)できます。私はそれがWindowsシステムのWinNT.hで定義されており、gccでも簡単に定義できることを知っています（まだ持っていない場合）。

UNREFERENCED PARAMETER(p) と定義されている

#define UNREFERENCED_PARAMETER(P)          (P)

WinNT.hで。

GCCのフラグなど、コンパイラのフラグを使用します。 -Wno-unused-variable

を使用__unusedして、変数が使用されない可能性があることをコンパイラに通知できます。

- (void)myMethod:(__unused NSObject *)theObject    
{
    // there will be no warning about `theObject`, because you wrote `__unused`

    __unused int theInt = 0;
    // there will be no warning, but you are still able to use `theInt` in the future
}

C ++ 11では、これは私が使用しているソリューションです。

template<typename... Ts> inline void Unreferenced(Ts&&...) {}

int Foo(int bar) 
{
    Unreferenced(bar);
    return 0;
}

int Foo2(int bar1, int bar2) 
{
    Unreferenced(bar1, bar2);
    return 0;
}

移植性があり（少なくとも最新のmsvc、clang、およびgccでは）、最適化が有効になっているときに余分なコードを生成しないことが確認されています。最適化なしで、追加の関数呼び出しが実行され、パラメーターへの参照がスタックにコピーされますが、関連するマクロはありません。

追加のコードに問題がある場合は、代わりに次の宣言を使用できます。

(decltype(Unreferenced(bar1, bar2)))0;

しかし、その時点で、マクロは読みやすくなります。

#define UNREFERENCED(...) { (decltype(Unreferenced(__VA_ARGS__)))0; }

これはうまく機能しますが、C ++ 11が必要です

template <typename ...Args>
void unused(Args&& ...args)
{
  (void)(sizeof...(args));
}

提示された回答のほとんどがローカルの未使用変数に対してのみ機能し、未使用の静的グローバル変数に対してコンパイルエラーが発生することがわかりました。

未使用の静的グローバル変数の警告を抑制するために必要な別のマクロ。

template <typename T>
const T* UNUSED_VARIABLE(const T& dummy) { 
    return &dummy;
}
#define UNUSED_GLOBAL_VARIABLE(x) namespace {\
    const auto dummy = UNUSED_VARIABLE(x);\
}

static int a = 0;
UNUSED_GLOBAL_VARIABLE(a);

int main ()
{
    int b = 3;
    UNUSED_VARIABLE(b);
    return 0;
}

匿名名前空間の非静的グローバル変数については警告が報告されないため、これは機能します。

C ++ 11が必要ですが

 g++  -Wall -O3  -std=c++11 test.cpp

笑！私は、カオスによって破壊されたすべての異端をこの問題よりも明らかにするSOに別の質問があるとは思いません！

C ++ 17へのすべての敬意をもって、C ++コアガイドラインに明確なガイドラインがあります。AFAIR、2009年に戻って、このオプションは今日と同様に利用可能でした。そして誰かがそれをDoxygenのバグと見なすと言ったら、Doxygenにバグがあります

警告であなたの問題はわかりません。コンパイラーxyが（正しい）警告を発行するが、これらの変数はプラットフォームzに必要であることをメソッド/関数ヘッダーに文書化します。

警告は正しいので、オフにする必要はありません。プログラムを無効にすることはありませんが、理由があることを文書化する必要があります。