Comment puis-je mieux désactiver un avertissement sur les variables inutilisées?

J'ai une application multiplateforme et dans certaines de mes fonctions, toutes les valeurs transmises aux fonctions ne sont pas utilisées. Par conséquent, je reçois un avertissement de GCC me disant qu'il y a des variables inutilisées.

Quelle serait la meilleure façon de coder autour de l'avertissement?

Un #ifdef autour de la fonction?

#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
{

C'est si moche mais cela ressemble à la façon dont le compilateur préférerait.

Ou dois-je affecter zéro à la variable à la fin de la fonction? (ce que je déteste parce qu'il modifie quelque chose dans le flux du programme pour faire taire un avertissement du compilateur).

Existe-t-il une manière correcte?

Vous pouvez le placer dans l' (void)var;expression " " (ne fait rien) pour qu'un compilateur voit qu'il est utilisé. C'est portable entre les compilateurs.

Par exemple

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

Ou,

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

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

Dans GCC et Clang, vous pouvez utiliser la __attribute__((unused))directive du préprocesseur pour atteindre votre objectif.
Par exemple:

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

C ++ 17 fournit désormais l' [[maybe_unused]]attribut.

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

Assez agréable et standard.

Votre solution actuelle est la meilleure - commentez le nom du paramètre si vous ne l'utilisez pas. Cela s'applique à tous les compilateurs, vous n'avez donc pas besoin d'utiliser le pré-processeur pour le faire spécialement pour GCC.

Mise à jour C ++ 17

En C ++ 17, nous obtenons l'attribut [[peut-être_unused]] qui est couvert dans [dcl.attr.unused]

Le jeton d'attribut peut-être_unused indique qu'un nom ou une entité est peut-être intentionnellement inutilisé. Il doit apparaître au plus une fois dans chaque liste d'attributs et aucune clause d'argument d'attribut ne doit être présente. ...

Exemple:

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

Les implémentations ne doivent pas avertir que b n'est pas utilisé, que NDEBUG soit défini ou non. —Fin exemple]

Pour l'exemple suivant:

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

Clang et gcc génèrent tous deux un diagnostic à l'aide de -Wall -Wextra à la fois pour la barre et la barre inutilisée ( voir en direct ).

Lors de l'ajout de [[peut-être_unused]], les diagnostics sont réduits au silence:

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

voir en direct .

Avant C ++ 17

En C ++ 11, une forme alternative de la UNUSEDmacro pourrait être formée en utilisant une expression lambda ( via Ben Deane ) avec une capture de la variable inutilisée:

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

L'invocation immédiate de l'expression lambda doit être optimisée, dans l'exemple suivant:

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

on peut voir dans godbolt que l'appel est optimisé loin:

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

Une façon encore plus propre consiste à simplement commenter les noms de variables:

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

Un collègue vient de me montrer cette jolie petite macro ici

Pour plus de facilité, je vais inclure la macro ci-dessous.

#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))

gccne signale pas ces avertissements par défaut. Cet avertissement doit avoir été activé explicitement en passant -Wunused-parameterau compilateur ou implicitement en passant -Wall -Wextra(ou éventuellement une autre combinaison d'indicateurs).

Les avertissements de paramètres inutilisés peuvent simplement être supprimés en passant -Wno-unused-parameterau compilateur, mais notez que cet indicateur de désactivation doit venir après tout indicateur d'activation possible pour cet avertissement dans la ligne de commande du compilateur, afin qu'il puisse prendre effet.

moyen sans macro et portable pour déclarer un ou plusieurs paramètres comme inutilisés:

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

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

L'utilisation de directives de préprocesseur est considérée comme malfaisante la plupart du temps. Idéalement, vous voulez les éviter comme le ravageur. N'oubliez pas qu'il est facile de faire comprendre votre code au compilateur, ce qui permet aux autres programmeurs de comprendre votre code est beaucoup plus difficile. Quelques dizaines de cas comme celui-ci ici et là, il est très difficile à lire pour vous-même plus tard ou pour d'autres en ce moment.

Une façon pourrait être de rassembler vos paramètres dans une sorte de classe d'arguments. Vous pouvez alors utiliser uniquement un sous-ensemble de variables (équivalent à votre affectation réelle de 0) ou avoir différentes spécialisations de cette classe d'arguments pour chaque plate-forme. Cela pourrait cependant ne pas en valoir la peine, vous devez analyser si cela conviendrait.

Si vous pouvez lire des modèles impossibles, vous trouverez peut-être des conseils avancés dans le livre "Exceptional C ++". Si les gens qui liraient votre code pourraient obtenir leur compétence pour englober les trucs fous enseignés dans ce livre, alors vous auriez un beau code qui peut également être facilement lu. Le compilateur serait également bien conscient de ce que vous faites (au lieu de tout cacher en prétraitant)

Tout d'abord, l'avertissement est généré par la définition de variable dans le fichier source et non dans le fichier d'en-tête. L'en-tête peut rester vierge et devrait, car vous pourriez utiliser quelque chose comme doxygen pour générer la documentation de l'API.

Je suppose que vous avez une implémentation complètement différente dans les fichiers source. Dans ces cas, vous pouvez soit commenter le paramètre incriminé, soit simplement écrire le paramètre.

Exemple:

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

Cela peut sembler cryptique, a donc défini une macro comme UNUSED. Voici comment MFC l'a fait:

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

Comme cela, vous voyez l'avertissement toujours dans les versions de débogage, peut être utile.

N'est-il pas sûr de toujours commenter les noms des paramètres? Si ce n'est pas le cas, vous pouvez faire quelque chose comme

#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))

C'est un peu moins moche.

J'ai vu cela au lieu de la (void)param2façon de faire taire l'avertissement:

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

On dirait que cela a été ajouté en C ++ 11

Utiliser un UNREFERENCED_PARAMETER(p)pourrait fonctionner. Je sais qu'il est défini dans WinNT.h pour les systèmes Windows et peut également être facilement défini pour gcc (s'il ne l'a pas déjà).

UNREFERENCED PARAMETER(p) est défini comme

#define UNREFERENCED_PARAMETER(P)          (P)

dans WinNT.h.

Utilisez l'indicateur du compilateur, par exemple l'indicateur pour GCC: -Wno-unused-variable

Vous pouvez utiliser __unusedpour indiquer au compilateur que la variable peut ne pas être utilisée.

- (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
}

En C ++ 11, voici la solution que j'utilise:

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;
}

Vérifié pour être portable (au moins sur msvc moderne, clang et gcc) et ne pas produire de code supplémentaire lorsque les optimisations sont activées. Sans optimisation, l'appel de fonction supplémentaire est effectué et les références aux paramètres sont copiées dans la pile, mais aucune macro n'est impliquée.

Si le code supplémentaire pose problème, vous pouvez utiliser cette déclaration à la place:

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

mais à ce stade, une macro offre une meilleure lisibilité:

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

Cela fonctionne bien mais nécessite C ++ 11

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

J'ai trouvé que la plupart des réponses présentées ne fonctionnent que pour la variable locale inutilisée et entraîneront une erreur de compilation pour la variable globale statique inutilisée.

Une autre macro devait supprimer l'avertissement de variable globale statique inutilisée.

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;
}

Cela fonctionne car aucun avertissement ne sera signalé pour la variable globale non statique dans l'espace de noms anonyme.

C ++ 11 est cependant requis

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

Lol! Je ne pense pas qu'il y ait une autre question sur SO qui révèle tous les hérétiques corrompus par le Chaos mieux que celui-ci!

Avec tout le respect que je dois à C ++ 17, il y a une ligne directrice claire dans C ++ Core Guidelines . AFAIR, en 2009, cette option était disponible ainsi qu'aujourd'hui. Et si quelqu'un dit que c'est considéré comme un bug dans Doxygen, alors il y a un bug dans Doxygen

Je ne vois pas votre problème avec l'avertissement. Documentez dans l'en-tête méthode / fonction que le compilateur xy émettra un avertissement (correct) ici, mais que ces variables sont nécessaires pour la plateforme z.

L'avertissement est correct, pas besoin de le désactiver. Cela n'invalide pas le programme - mais il doit être documenté, qu'il y a une raison.