Jak najlepiej wyciszyć ostrzeżenie o nieużywanych zmiennych?

Mam aplikację wieloplatformową i w niektórych moich funkcjach nie wszystkie wartości przekazywane do funkcji są wykorzystywane. Dlatego dostaję ostrzeżenie od GCC z informacją, że istnieją nieużywane zmienne.

Jaki byłby najlepszy sposób kodowania wokół ostrzeżenia?

#Ifdef wokół funkcji?

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

Jest to tak brzydkie, ale wydaje się, że preferuje to kompilator.

Czy też przypisuję zero do zmiennej na końcu funkcji? (którego nienawidzę, ponieważ zmienia coś w przepływie programu, aby wyciszyć ostrzeżenie kompilatora).

Czy jest właściwy sposób?

Możesz umieścić go w (void)var;wyrażeniu „ ” (nic nie robi), aby kompilator zobaczył, że jest używany. Jest to przenośne między kompilatorami.

Na przykład

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

Lub,

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

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

W GCC i Clang możesz użyć __attribute__((unused))dyrektywy preprocesora, aby osiągnąć swój cel.
Na przykład:

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

C ++ 17 udostępnia teraz ten [[maybe_unused]]atrybut.

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

Całkiem miły i standardowy.

Twoje obecne rozwiązanie jest najlepsze - skomentuj nazwę parametru, jeśli go nie używasz. Dotyczy to wszystkich kompilatorów, więc nie musisz używać procesora wstępnego, aby zrobić to specjalnie dla GCC.

Aktualizacja C ++ 17

W C ++ 17 otrzymujemy atrybut [[może_nieużywany]], który jest objęty [dcl.attr.unused]

Token atrybutu może być nieużywany oznacza, że ​​nazwa lub jednostka jest prawdopodobnie celowo nieużywana. Pojawia się najwyżej raz na każdej liście atrybutów i nie może występować żadna klauzula argument-atrybut. ...

Przykład:

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

Implementacje nie powinny ostrzegać, że b jest nieużywane, niezależnie od tego, czy zdefiniowano NDEBUG. —Przykład]

Dla następującego przykładu:

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

Zarówno clang, jak i gcc generują diagnostykę przy użyciu -Wall -Wextra zarówno dla bar, jak i unused_bool ( Zobacz na żywo ).

Podczas dodawania [[może_nieużywany]] wycisza się diagnostyka:

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

zobacz to na żywo .

Przed C ++ 17

W C ++ 11 można utworzyć alternatywną formę UNUSEDmakra przy użyciu wyrażenia lambda ( przez Bena Deane'a ) z przechwyceniem nieużywanej zmiennej:

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

Natychmiastowe wywołanie wyrażenia lambda powinno zostać zoptymalizowane, biorąc pod uwagę następujący przykład:

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

widzimy w godbolt, że połączenie jest zoptymalizowane:

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

Jeszcze czystszym sposobem jest po prostu komentowanie nazw zmiennych:

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

Współpracownik właśnie wskazał mi to miłe małe makro tutaj

Dla ułatwienia dołączę poniższe makro.

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

gccdomyślnie nie oznacza tych ostrzeżeń. To ostrzeżenie musiało zostać włączone jawnie przez przekazanie -Wunused-parameterdo kompilatora lub pośrednio przez przekazanie -Wall -Wextra(lub ewentualnie inną kombinację flag).

Nieużywane ostrzeżenia dotyczące parametrów można po prostu ukryć, przekazując -Wno-unused-parameterdo kompilatora, ale należy pamiętać, że ta flaga wyłączająca musi pojawić się po ewentualnych flagach włączających dla tego ostrzeżenia w wierszu polecenia kompilatora, aby mogła zadziałać.

bez makr i przenośny sposób na zadeklarowanie jednego lub więcej parametrów jako nieużywanych:

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

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

Korzystanie z dyrektyw preprocesora jest przez większość czasu uważane za zło. Idealnie chcesz ich uniknąć, jak szkodników. Pamiętaj, że zrozumienie kodu przez kompilator jest łatwe, a innym programistom zrozumienie kodu jest znacznie trudniejsze. Kilkadziesiąt takich przypadków tutaj i tam bardzo utrudnia czytanie sobie później lub innym.

Jednym ze sposobów może być zestawienie parametrów w jakąś klasę argumentów. Następnie możesz użyć tylko podzbioru zmiennych (tak jak w rzeczywistości przypisujesz 0) lub posiadasz różne specjalizacje tej klasy argumentów dla każdej platformy. Może to jednak nie być tego warte, musisz przeanalizować, czy będzie pasować.

Jeśli umiesz czytać niemożliwe szablony, możesz znaleźć zaawansowane porady w książce „Wyjątkowe C ++”. Gdyby ludzie, którzy czytali Twój kod, mogliby zdobyć swój zestaw umiejętności obejmujący szalone rzeczy nauczane w tej książce, miałbyś piękny kod, który można łatwo odczytać. Kompilator byłby również świadomy tego, co robisz (zamiast ukrywać wszystko przez wstępne przetwarzanie)

Po pierwsze ostrzeżenie jest generowane przez definicję zmiennej w pliku źródłowym, a nie w pliku nagłówkowym. Nagłówek może pozostać nieskazitelny i powinien, ponieważ do generowania dokumentacji API możesz używać czegoś takiego jak doxygen.

Zakładam, że masz zupełnie inną implementację w plikach źródłowych. W takich przypadkach możesz albo skomentować obrażający parametr, albo po prostu napisać parametr.

Przykład:

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

Może to wydawać się tajemnicze, więc zdefiniowane makro takie jak UNUSED. Sposób, w jaki MFC to zrobił:

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

W ten sposób ostrzeżenie nadal pojawia się w kompilacjach debugowania, może być pomocne.

Czy zawsze nie jest bezpiecznie komentować nazwy parametrów? Jeśli nie, możesz zrobić coś takiego

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

To trochę mniej brzydkie.

Widziałem to zamiast (void)param2wyciszenia ostrzeżenia:

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

Wygląda na to, że zostało to dodane w C ++ 11

Korzystanie z UNREFERENCED_PARAMETER(p)może działać. Wiem, że jest zdefiniowany w WinNT.h dla systemów Windows i może być łatwo zdefiniowany również dla gcc (jeśli jeszcze go nie ma).

UNREFERENCED PARAMETER(p) jest zdefiniowany jako

#define UNREFERENCED_PARAMETER(P)          (P)

w WinNT.h.

Użyj flagi kompilatora, np. Flagi dla GCC: -Wno-unused-variable

Możesz użyć, __unusedaby powiedzieć kompilatorowi, że zmienna może nie być używana.

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

W C ++ 11 używam tego rozwiązania:

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

Zweryfikowano, że jest przenośny (przynajmniej w nowoczesnych msvc, clang i gcc) i nie generuje dodatkowego kodu, gdy włączone są optymalizacje. Bez optymalizacji wykonywane jest dodatkowe wywołanie funkcji, a odniesienia do parametrów są kopiowane na stos, ale nie są w to zaangażowane makra.

Jeśli problem stanowi dodatkowy kod, możesz zamiast tego użyć tej deklaracji:

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

ale w tym momencie makro zapewnia lepszą czytelność:

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

Działa to dobrze, ale wymaga C ++ 11

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

Odkryłem, że większość przedstawionych odpowiedzi działa tylko dla lokalnej nieużywanej zmiennej i spowoduje błąd kompilacji dla nieużywanej statycznej zmiennej globalnej.

Kolejne makro potrzebne do ukrycia ostrzeżenia o nieużywanej statycznej zmiennej globalnej.

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

Działa to, ponieważ nie będzie generowane ostrzeżenie dla niestatycznej zmiennej globalnej w anonimowej przestrzeni nazw.

Wymagany jest jednak C ++ 11

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

Lol! Nie sądzę, żeby było inne pytanie na temat SO, które ujawniło wszystkich heretyków skorumpowanych przez Chaos lepiej niż to!

Z całym szacunkiem dla C ++ 17 istnieje wyraźna wytyczna w Podstawowych Wytycznych C ++ . AFAIR, jeszcze w 2009 roku ta opcja była dostępna tak samo jak dzisiaj. A jeśli ktoś powie, że w Doxygen jest uważany za błąd, oznacza to, że w Doxygen jest błąd

Nie widzę twojego problemu z ostrzeżeniem. Udokumentuj to w nagłówku metody / funkcji, że kompilator xy wyda tutaj (poprawne) ostrzeżenie, ale te zmienne są potrzebne dla platformy z.

Ostrzeżenie jest prawidłowe, nie trzeba go wyłączać. Nie unieważnia to programu - należy go jednak udokumentować, że istnieje powód.