Quali sono le conseguenze dell'ignorare: avviso: parametro inutilizzato

Question

Sto lavorando a un progetto C ++ e ho notato che abbiamo una serie di avvertimenti sui parametri non utilizzati.

Che effetto potrebbe avere se questi avvisi vengono ignorati?

Answer 1

La funzione con un parametro non utilizzato può presentare un bug reale nei seguenti casi:

1. Esiste un parametro output , che non viene assegnato o scritto, con conseguente valore indefinito per il chiamante.

2. Uno dei parametri è un puntatore alla funzione di callback, che è necessario richiamare e dimenticare di farlo. Può accadere se ci sono molti #ifdef nella funzione.

3. Si dichiara una variabile locale con lo stesso nome che ombreggia un parametro e successivamente si utilizza il valore errato nella funzione.

Non utilizzare un input i parametri potrebbero essere innocui, ma è possibile ridurre il rumore per visualizzare avvisi utili contrassegnando esplicitamente i parametri di input non utilizzati all'inizio della funzione eseguendo il cast su void (funziona sia in C che in C ++):

(void)param1;

In alternativa,

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

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

O ometti il ??nome del parametro (solo C ++):

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

Answer 2

Se hai molti avvisi non importanti che non sono importanti per te, potresti trascurare l'importante avvertimento sulla riga di codice che hai appena scritto che si nasconde nel mezzo di essi.

Answer 3

Per un modo specifico di gcc per disabilitare l'avviso, puoi usare __attribute __ ((non utilizzato)) come

void foo(int a, int b __attribute__((unused))) {

}

Per ignorare il secondo parametro. Se il tuo programma fa già affidamento sulle tecnologie GCC, puoi utilizzare quell'attributo per essere sicuro al 100% da quel tipo di avviso.

Answer 4

Significa che hai scritto una funzione che accetta un parametro ma non usa il parametro. È innocuo ma in alcuni casi potrebbe indicare bug.

In genere è possibile silenziare questo avviso rimuovendo il nome del parametro, lasciandolo anonimo, ma ciò potrebbe non essere desiderabile a seconda del motivo per cui il parametro non viene utilizzato.

Suggerirei di disattivare l'avviso se sta rendendo più difficile trovare i veri problemi.

Answer 5

In C ++ puoi avere argomenti predefiniti:

int sum(int first, int second=0){   // should not give warning
    return first+first;
}

Puoi anche avere argomenti extra:

int sum(int first, int second){     // should give warning
    first *= 2;
    return first;
}

Se hai un parametro che non stai usando e non è predefinito, dovresti ricevere un avviso perché stai chiedendo al programma di passare allo stack valori extra a cui non si fa mai riferimento, e quindi sta facendo più lavoro di quanto dovrebbe.

Forse significa che hai dimenticato anche parte della logica della funzione.

Answer 6

Nessuno. tranne [EDIT]: come altri hanno sottolineato, potresti avere un parametro di output non assegnato.

Dovresti pulirli, perché in molte occasioni ho visto gli sviluppatori ignorare importanti avvisi che erano "nascosti" in un gran numero di avvisi, ed erano così abituati a vedere avvisi che non li hanno mai prestati. Cerco di avere zero avvisi in ogni momento e impostare gli avvisi del compilatore al livello massimo.

Answer 7

Dipende se intendevi usare il paramater. Per es.

const int Size = 12; // intended for use in some other function

char* MakeBuffer(int size)
{
   return new char[Size];
}

In questo codice 'size' non è utilizzato e viene invece utilizzata la costante 'Size'. Quindi l'avviso evidenzierà problemi di questo tipo per te.

Tuttavia, se non hai mai indentato l'uso del parametro, è necessario rimuoverlo dalla firma del metodo. A meno che non sia necessario abbinare una firma per un metodo virtuale o un puntatore a funzione, in tal caso non è possibile rimuoverlo.

Answer 8

Se un metodo non utilizza un parametro, la prima domanda che si pone è perché, in primo luogo, quel parametro fa parte della firma del metodo. Questi avvertimenti hanno un senso dal momento che è una cattiva progettazione a cui si riferiscono e, inoltre, c'è un piccolo sovraccarico e che ogni volta che viene chiamato questo metodo, questo parametro viene inserito nello stack, quindi il migliore è refactoring del metodo e rimuovere parametri che non hanno alcun uso.

Detto questo, lasciare questi parametri non fa molto male se non per un piccolo sovraccarico che ho citato.