unreferenzierter formaler Parameter
-
Hallo Source.
Also wenn ich UNUSED(z); verwende erhalte ich die selbe Warnung. Wenn ich ohne Semikolon schreibe erhalte ich sogar Fehlermeldungen.
-
Bei Debug-Builds kommt die Meldung trotzdem. Im Release verschwindet sie dann. Du kannst auch UNUSED_ALWAYS verwenden. Das funktioniert in beiden Konfigurationen.
-
Achso. Gut Vielen Dank.
-
Besser so:
void Foo(int x, int y, int /*z*/) { int res = x * y; // bla }
-
Hallo Martin
Ok. Sieht auch besser aus :-). Das macht man aber dann nur in der Implementierung und nicht Deklaration oder? Was ist wenn die Funktion Inline ist?
-
Die übliche Variante ist wohl den Namen nur bei der Definition wegzulassen, nicht aber bei der Deklaration. Man kann aber auch bei beiden, der Parametername ist immer optional. (Also auch bei inline Funktionen)
-
Ok. Danke
Darf ich dann nochmals nachfragen. Wie sieht es bei einer Referenz aus:
so:
void Foo(int x, int y, const int /*&z*/) { ... }
oder so:
void Foo(int x, int y, const int &/*z*/) { ... }
Und mal abgesehen davon. Habe das bisher noch nie irgenwo gesehen. Also dass man den Namen weglässt. Also ich verwende z.B. die Serialisierung von boost
Die Funktionsdefinition sieht ja wie folgt aus
void serialize(Archive &ar, const unsigned int version) { ... }
Hier benötigt man in den seltensten Fällen den Parameter "version". Wenn ich mir hier verschiedenste Beispiele anschaue. Ich habe noch keines gesehen wo der Name "version" weggelassen wurde.
-
y-vonne schrieb:
Wie sieht es bei einer Referenz aus:
so:void Foo(int x, int y, const int /*&z*/) { ... }
oder so:
void Foo(int x, int y, const int &/*z*/) { ... }
Die Typen in der Definition der Funktion müssen mit den Typen in der Deklaration übereinstimmen.
int ist ein anderer Typ als int&, demnach die zweite Variante.void serialize(Archive &ar, const unsigned int version) { ... }
Hier benötigt man in den seltensten Fällen den Parameter "version". Wenn ich mir hier verschiedenste Beispiele anschaue. Ich habe noch keines gesehen wo der Name "version" weggelassen wurde.
Eine Warnung bedeutet ja nicht unbedingt einen Fehler.
-
Eine Warnung bedeutet ja nicht unbedingt einen Fehler.
Ja genau. Das war ja meine Frage. -->
Ignorieren?
Versucht man z.B. die Tipps von Scott Meyers umzusetzen wie es da heißt: "Allerdings gilt es allgemein als die bessere Vorgehensweise, Code zu schreiben, der Wartungsfrei kompiliert wird, sogar auf der höchsten Warnstufe." Dann ist das ja nicht so gut.
-
y-vonne schrieb:
Und mal abgesehen davon. Habe das bisher noch nie irgenwo gesehen. Also dass man den Namen weglässt. Also ich verwende z.B. die Serialisierung von boost
(...)
Hier benötigt man in den seltensten Fällen den Parameter "version". Wenn ich mir hier verschiedenste Beispiele anschaue. Ich habe noch keines gesehen wo der Name "version" weggelassen wurde.Nur dass du es noch nie gesehen hast, heisst nicht, dass es unüblich wäre.
Ich hab' das einerseits selbst schon oft geschrieben, und andrerseits selbst schon oft in fremdem Code gesehen.Wo es z.B. wirklich sehr häufig gemacht wird ist bei "Dummy Parametern" wo man nur den Typ benötigt. Beispielsweide bei
operator ++ (int)
oder überall wo man boost::type<T> Parameter verwendet.BTW: ich compiliere zwar einige Projekte mit /W4 (höchste Warning Stufe bei MSVC), allerdings verwenden wir in der Firma ein Header-File das etliche Warnings global deaktiviert. MSVC macht mit /W4 wegen den beknacktesten Dingen eine Warning. Kleiner Auszug:
#pragma warning(disable: 4675) // resolved overload was found by argument-dependent lookup #pragma warning(disable: 4324) // 'xxx' : structure was padded due to __declspec(align()) #pragma warning(disable: 4510) // default constructor could not be generated #pragma warning(disable: 4511) // copy constructor could not be generated #pragma warning(disable: 4512) // assignment operator could not be generated #pragma warning(disable: 4610) // 'class' can never be instantiated - user defined constructor required #pragma warning(disable: 4251) // class 'xxx' needs to have dll-interface to be used by clients of class 'yyy' #pragma warning(disable: 4275) // non dll-interface class 'xxx' used as base for dll-interface class 'yyy'
-
Na. Ok. Vielen Dank für eure Hilfe. Abschalten würde ich die Warnung ungerne. Habe sie gerade erst endeckt und sie hat mich gleich auf ein paar Funktionen hingewisen wo ich vergessen hatte nen Parameter weiterzu leiten.
Auf der anderen Seite habe ich sehr viele Funktionen wo der Parameter nicht benötigt wird. Dann müsste ich alle durchgehen und auskommentieren. Puh. Viel Arbeit.
Jetzt mal schauen so, weiß nun nicht ganz wie ich vorgehe.