Inutilisés paramètre en c++11

En c++03 et plus tôt pour désactiver l'avertissement du compilateur sur inutilisé paramètre j'ai l'habitude d'utiliser ce type de code:

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

Par exemple 

int main(int argc, char *argv[])
{
    UNUSED(argc);
    UNUSED(argv);

    return 0;
}

Mais les macros ne sont pas les meilleures pratiques pour le c++, donc.
N'importe quelle meilleure solution apparaissent avec c++11? Je veux dire que je peux me débarasser des macros?

Merci pour tout!

  • Assurez-vous. Désactiver l'avertissement.
  • Non! Ne pas le faire!
  • Comment beaucoup mieux, c'est que la macro que de l'élargir inline? (void)argc; est plus court et plus clair que UNUSED(argc);
  • J'aime unused(argc, argv) avec template<class... T> void unused(T&&...){}. Clair, concis, et sans macros.
  • oh non les macros doivent pas utiliser les macros
  • Si un paramètre n'est pas utilisé, pourquoi est-il là en premier lieu?
  • Parfois, vous avez besoin pour se conformer à une certaine interface (par exemple lors du remplacement d'une fonction virtuelle ou en programmation générique).
  • s/sometimes/most of the time/
  • mais vous pouvez laisser sans nom de l'argument, ou même juste un commentaire, c'est le nom. void foo(int /*unused_arg*/, int used_arg)
  • Qui ne peut pas être fait pour "peut-être" utilisé des arguments, par exemple, conditionnel à l'inclusion où une branche besoin de l'argumentation et de l'autre branche n'a pas. Les envelopper également dans #ifdef est trop verbeux. Il n'y aurait [[maybe_unused]] en C++17, mais il arrive trop tard.
  • C'est pas tout à fait idéal, car "inutilisé" peut indiquer de travailler non seulement sur des arguments, mais aussi des expressions. J'utilise cette construction pour exprimer explicitement prévu séquencé d'évaluation sur la non-void expressions. Otoh, que, "non utilisé" est utilisé plus généralement, mise en œuvre de coulée à vide.
  • C'est assez proche de ce que j'utilise mais j'ai récemment trouver il ne peut pas travailler pour le paramètre packs. C'est pourquoi je recherche pour la réponse et vient ici. Malheureusement je n'arrive toujours pas à trouver une solution portable idéale.
  • Vous ne devriez pas donner de réponse à votre question. Il est injuste wrt qui répond à votre question.

InformationsquelleAutor inkooboo | 2013-04-02
  1. 39

    J'ai utilisé une fonction dont le corps est vide à cette fin:

    template <typename T>
void ignore(T &&)
{ }

void f(int a, int b)
{
  ignore(a);
  ignore(b);
  return;
}

    Je m'attendre à des graves compilateur d'optimiser l'appel de la fonction et des silences mises en garde pour moi.

    • T && n'acceptera pas de paramètre (paramètre est la l-valeur), il sera? Serait ignorer(T const &) le plus approprié?
    • Lorsque T est un paramètre du modèle, T&& est un de référence universel, qui se lie à quoi que ce soit.
    • Hmm, intéressant...!
    • +1, Même si Xeo's version avancée de son commentaire n'est même pas mentionné.
    • Pourquoi ignorer la méthode intégrée? Tout simplement omettre le nom du paramètre.
    • Vous pouvez utiliser variadic template pour écrire quelque chose comme ignore(a, b, anythingElseThatBothersYou);
    • -1, c'est ridicule et inutile engin, surtout quand vous pouvez omettre le paramètre nom. Franchement, ça me dérange que cela a 25 upvotes en quelque sorte.
    • Cela rend votre code explicite sur ce qu'il fait et pourquoi. Ayant inutilisés de paramètres ou de variables est une odeur dans votre code, et cela rend explicite. La désactivation de l'alerte de votre code odeur plus.
    • il n'y a pas d'avertissement si vous tout simplement omettre le nom et l'ayant pas de nom pour faire référence à la variable rend explicite le fait que vous ne l'utilisez pas sans avoir à ajouter de la météorisation.
    • Essayez de l'utiliser dans un constexpr fonction.
    • unname eux, de sorte que la fonction accepte le paramètre, mais ne pas l'affecter à une variable: int main( int /* argc */, char ** /* argv */ )
    • Ne pas réinventer la roue ! Utilisez le boost, voir la réponse ci-dessous
    • Je comprends que la question était pour les paramètres, mais sa réponse peut être utilisé pour le RAII-classe de style comme std::lock_guard. Vous n'avez pas "utiliser" ce genre de classe et ne veulent pas d'un avertissement...
    • Le nom n'est pas assez bon et pourrait s'opposer à std::ignore si l'on a utilisé using namespace std; naïvement.
    • Peut-être que l'on doit déclarer la ignore fonction inline. (Si la fonction est mis dans un fichier d'en-tête et le compilateur n' pas optimiser, alors il pourrait y avoir plusieurs instances de la même spécialisation dans les fichiers de l'objet.)
    • boost/core/ignore_unused la met en œuvre, de la même façon, donc je pense que c'est une bonne solution. Si boost constaté que cette méthode est utile enoug de l'inclure dans sa bibliothèque, je dirais qu'il doit y avoir une bonne raison de ne pas simplement en commentaire les noms de paramètre...

    InformationsquelleAutor MadScientist
  2. 189

    Vous pouvez simplement omettre les noms de paramètre:

    int main(int, char *[])
{

    return 0;
}

    Et dans le cas de la main, vous pouvez omettre les paramètres tout à fait:

    int main()
{
    //no return implies return 0;
}

    Voir "§ 3.6 de Début et de fin" dans le C++11.

    • Et dans le cas de main, vous pouvez omettre les paramètres tout à fait. Et le return déclaration, pour cette question.
    • J'ai effectivement considérer les bonnes pratiques d'omettre l'instruction return.
    • Ok, je vais mordre. Pourquoi ne vous considérez que c'est une bonne pratique?
    • Si c'est la valeur de retour par défaut qui se termine principal, je l'omettre, car il est inutile standard.
    • J'ai presque toujours omettre main's return 0 dans un cas de test, mais presque toujours écrire l'auto-documentation return EXIT_SUCCESS dans le code de production. Que's bonne pratique!
    • cela semble être la meilleure réponse à moi - tout ce qui futzes avec des macros ou des modèles n'est pas toujours de s'assurer que la variable ne peut pas être utilisé par la suite. Cette fois, les silences de l'avertissement et s'assure que l' (sans nom) le paramètre ne peut pas être utilisée.
    • Pourtant, au moins deux autres réponses dire la même chose, en plus d'autres choses, et en fait l'adresse de la question. Ce ne pas.
    • À propos de "dire la même chose": c'est exact, et je ne sais pas pourquoi ma réponse reçoit le plus upvotes. Peut-être parce qu'il était le premier. Sur "effectivement en train de régler le problème": oui je pouvais avoir explicitement déclaré, "Il n'y a pas de nouvelles C++11 fonctionnalité", mais la réponse implique clairement il n'est pas nécessaire pour une telle fonction (ou d'utiliser les macros) pour arrêter l'alerte.
    • Cela fonctionne dans le cas où vous n'avez jamais reportez-vous à l'argument, mais sont obligés de le recevoir (par exemple, dans la principale, ou une fonction virtuelle vous est prépondérante). Cependant, il est moins utile si vous ne reportez-vous à l'argument dans une configuration debug par exemple. Conditionnellement en omettant le nom du paramètre va finir par être assez laid! 🙂
    • Cela le rend beaucoup plus difficile à lire le code, vous devez vous référer à l'en-tête où espérons-le, les noms de paramètres ont été laissés dans le but de comprendre les variables qui ont été ignorées. Mieux les mettre en commentaires.
    • Necro commentaire, mais au lieu de ommiting, vous pouvez toujours les mettre en commentaires. Il faut plus de quatre caractères et toutes les informations dont vous avez besoin est toujours à la source, sans satanés avertissements.

    InformationsquelleAutor Henrik
  3. 44

    Il est le <tuple> dans C++11, qui comprend le prêt à usage std::ignorer objet, qui permet d'écrire (très probablement sans imposer d'exécution frais généraux):

    void f(int x)
{
    std::ignore = x;
}
    • Considérant que c'est dans la bibliothèque standard et, par conséquent, n'implique pas de devoir écrire des fonctions personnalisées, je dirais que c'est la meilleure solution!
    • Cette classe est "Conçu pour être utilisé avec std::cravate lors de la décompression d'un std::tuple", pas pour ce cas d'utilisation. Je dirais que c'est une solution, mais probablement pas la meilleure.
    • J'aime cette ignorent en fait.. Bce, si vous pouvez supprimer le paramètre de suppression de ce lieu (ce qui serait la meilleure solution dans tous les cas).
    InformationsquelleAutor Orient
  4. 30

    Rien d'équivalent, pas de.

    Donc, vous êtes coincé avec la même vieille options. Êtes-vous heureux d'omettre les noms dans la liste des paramètres entièrement?

    int main(int, char**)

    Dans le cas spécifique de main, bien sûr, vous pourriez tout simplement omettre les paramètres eux-mêmes:

    int main()

    Il y a aussi typique de mise en œuvre-astuces spécifiques, tels que GCC est __attribute__((unused)).

    InformationsquelleAutor Lightness Races BY-SA 3.0
  5. 28

    À "désactiver" cet avertissement, le mieux est d'éviter l'écriture de l'argument, il suffit d'écrire le type.

    void function( int, int )
{
}

    ou si vous préférez, en commentaire:

    void function( int /*a*/, int /*b*/ )
{
}

    Vous pouvez mélanger nommé et sans nom d'arguments:

    void function( int a, int /*b*/ )
{
}

    Avec C++17 vous avez [[maybe_unused]] attribut prescripteur, comme:

    void function( [[maybe_unused]] int a, [[maybe_unused]] int b )
{
}
    • J'ai utilisé pour ce faire, mais il devient rapidement une douleur depuis que vous ne pouvez plus vous en commentaire de gros morceaux de code avec /* ... */
    • C'est vrai, mais les Ide modernes je suppose que si vous sélectionnez un bloc de commentaire automatiquement, il va ajouter un tas de "//" au début de chaque ligne. C'est ce que Eclipse CDT n'. Personnellement, je n'utilise que le premier exemple n'ayant pas de nom. (vous pouvez mettre des noms dans les déclarations de dans un .h de fichier par exemple).
    • Quand je veux commenter gros morceau de code, j'utilise #if 0 ... #endif, qui sont autorisés à être imbriqués et entrent jamais en conflit avec l'existant /* ... */ commentaires.
    • Et la plupart des éditeurs et des IDEs de soutien au vieillissement de la sortie #if 0 blocs comme un cas particulier, même si elles ne prennent pas en charge complète de préprocesseur intellisense.
    InformationsquelleAutor Nikko
  6. 14

    Macros peut-être pas idéal, mais ils font un bon travail pour cet usage particulier. Je dirais bâton à l'aide de la macro.

    • +1: Dans ce cas, ils provoquent de zéro blessure et résoudre un problème. Je ne vois pas de raison (au-delà du ridicule, sans fondement, le mantra de "ne jamais utiliser une macro") de ne pas employer ici.
    • Quel est l'avantage d'une macro plus en omettant le nom du paramètre en tout?
    • Comme l'a souligné Angew, un problème est que vous pouvez réellement utiliser le paramètre avant/après à l'aide des macros; idiot droit ? Ainsi, dans le code qui est lourd avec un prétraitement des directives, il n'est pas immédiat que vous êtes actuellement dans une branche qui est à l'aide du paramètre ou pas 🙁
    • Certains paramètres peuvent uniquement être utilisé lorsque certains de prétraitement des constantes sont définies (en général, en Debug).
    • J'avais appeler la macro MAYBE_UNUSED, pour cette raison; en général, je n'aime pas si je l'ai dit "ne vous inquiétez pas si je ne l'utilise pas en-dessous de" mais il va le faire de toute façon.
    • juste assez 🙂
    • Ok, donc la bonne chose est probablement l'appeler "HIDE_UNUSED_WARNING". Mais je pense tout de même que l'utilisation d'une macro ici est un bon idée. Tant que la macro est nommé d'une manière telle que cela ne cause pas de confusion et/ou de conflits avec d'autres codes.
    • si l'utilisation des paramètres sont utilisés uniquement à l'intérieur de certaines #ifdef blocs, vous pouvez mettre le nom du paramètre à l'intérieur d'un tel bloc de trop.
    • Oui... mais c'est assez contraignant car #ifdef et #endif directives doivent être placés sur la ligne de leur propre, qui, en réalité, visser la tête de la fonction... au point d'être quasiment illisible.

    InformationsquelleAutor Mats Petersson
  7. 13

    Ce que vous avez à l'encontre de l'ancien et du moyen standard?

    void f(int a, int b)
{
  (void)a;
  (void)b;
  return;
}
    • Je trouve que certains compilateurs sont heureux avec cela, mais certains compilateurs sont plus pointilleux que d'autres. La croix-Plate-forme de travail doit être testée dans tous des OS et des compilateurs pour être sûr qu'ils sont tous satisfaits de la solution.
    InformationsquelleAutor jcayzac
  8. 12

    Il n'y a rien de nouveau disponible.

    Ce qui fonctionne le mieux pour moi est de mettre en commentaire le nom du paramètre dans la mise en œuvre. De cette façon, vous vous débarrasser de l'avertissement, mais conservent encore une certaine notion de ce que le paramètre est (puisque le nom est disponible).

    Votre macro (et tous les autres acteurs-à-void approche a l'inconvénient que vous pouvez réellement utiliser le paramètre après l'utilisation de la macro. Cela peut rendre le code plus difficile à maintenir.

    InformationsquelleAutor Reinstate Monica
  9. 12

    Le coup de pouce de l'en-tête <boost/core/ignore_unused.hpp> (Boost >= 1.56) définit, à cette fin, le modèle de fonction boost::ignore_unused().

    int fun(int foo, int bar)
{
  boost::ignore_unused(bar);
#ifdef ENABLE_DEBUG_OUTPUT
  if (foo < bar)
    std::cerr << "warning! foo < bar";
#endif

  return foo + 2;
}

    PS C++17 a la [[maybe_unused]] attribut supprime les avertissements sur inutilisé entités.

    • [[maybe_unused]] est explicite, actuellement le meilleur.
    InformationsquelleAutor manlio
  10. 0

    J'aime vraiment utiliser des macros pour cela, car elle permet un meilleur contrôle lorsque vous avez plusieurs versions de débogage (par exemple, si vous voulez construire avec affirme activé):

    #if defined(ENABLE_ASSERTS)
  #define MY_ASSERT(x) assert(x)
#else
  #define MY_ASSERT(x)
#end

#define MY_UNUSED(x)

#if defined(ENABLE_ASSERTS)
  #define MY_USED_FOR_ASSERTS(x) x
#else
  #define MY_USED_FOR_ASSERTS(x) MY_UNUSED(x)
#end

    et de l'utiliser ensuite comme:

    int myFunc(int myInt, float MY_USED_FOR_ASSERTS(myFloat), char MY_UNUSED(myChar))
{
  MY_ASSERT(myChar < 12.0f);
  return myInt;
}
    InformationsquelleAutor steeveeet
  11. 0

    J'ai ma propre mise en œuvre de critique de segments de code.
    J'ai fait des recherches un tout en un moment critique de code pour ralentir et avoir trouvé cette application consomme environ 2% à partir de la critique de code que j'ai optimisé:

    #define UTILITY_UNUSED(exp) (void)(exp)
#define UTILITY_UNUSED2(e0, e1) UTILITY_UNUSED(e0); UTILITY_UNUSED(e1)
#define ASSERT_EQ(v1, v2) { UTILITY_UNUSED2(v1, v2); } (void)0

    La critique de code a utilisé le ASSERT* définitions pour les fins de débogage, mais dans la version qu'il a clairement coupé, mais... Semble que celui-ci produit un peu plus rapide code dans Visual Studio 2015 Update 3:

    #define UTILITY_UNUSED(exp) (void)(false ? (false ? ((void)(exp)) : (void)0) : (void)0)
#define UTILITY_UNUSED2(e0, e1) (void)(false ? (false ? ((void)(e0), (void)(e1)) : (void)0) : (void)0)

    La raison en est double false ? expression. C'est en quelque sorte produit un peu plus rapide code dans la version avec l'optimisation maximale.

    Je ne sais pas pourquoi c'est plus rapide (qui semble être un bug dans l'optimisation du compilateur), mais c'est au moins une meilleure solution pour ce cas de code.

    Note:
    Le plus important ici est que une fois le code critique de ralentissements sans au-dessus des assertions ou inutilisés des macros dans le communiqué. En d'autres termes le double false ? expression étonnamment aide à optimiser un code.

    InformationsquelleAutor Andry
  12. -1

    windows.h définit UNREFERENCED_PARAMETER:

    #define UNREFERENCED_PARAMETER(P) {(P) = (P);}

    De sorte que vous pourriez faire comme ceci:

    #include <windows.h>
#include <stdio.h>
int main(int argc, char **argv) {
  UNREFERENCED_PARAMETER(argc);
  puts(argv[1]);
  return 0;
}

    Ou à l'extérieur de Windows:

    #include <stdio.h>
#define UNREFERENCED_PARAMETER(P) {(P) = (P);}
int main(int argc, char **argv) {
  UNREFERENCED_PARAMETER(argc);
  puts(argv[1]);
  return 0;
}
    • Ce n'est pas une très bonne option, car operator= peuvent avoir des effets secondaires.
    InformationsquelleAutor