Compilerfehler mit Template-Parameter = void* - Seite 10

Neuer Kommentar
 
Ilya Malev:
Und "normale Programmierer merken sich die Prioritäten von C++-Operationen wie ein Einmaleins",
Niemand hat eine solche These geäußert. Ich selbst verwende die Registerkarte in der Dokumentation
 
fxsaber:

Ganz genau! Ich bin überhaupt kein Profi, solche Warnungen haben mir schon 100 Mal geholfen.

Ich bin auch kein Profi, aber ich habe mich mehr als einmal über solche Warnungen geärgert, weil zwischen Dutzenden (und manchmal Hunderten) solcher überflüssigen Warnungen die wirklich wichtigen und notwendigen verloren gegangen sind

Und es ist unklar, welche Art von Warnungen Sie erhalten können, wenn Sie überall Klammern setzen? Und wenn es um andere Fälle ging, ist es nicht nötig, die Dinge zu vermischen.

 
A100:

Damit dieses Konzept im Compiler umgesetzt werden kann. Niemand verbietet, zusätzliche Klammern zu setzen. Die Frage bezieht sich auf unnötige Warnungen

Nun, im Studio wird dies durch einen Pegel konfiguriert.

Und eigentlich kann Sie niemand daran hindern, diese Warnungen zu entfernen, indem Sie den Code so ändern, dass der Compiler ihn mag

 
TheXpert:

Nun, im Studio wird sie durch einen Pegel eingestellt.

Und niemand hindert Sie daran, diese Warnungen zu entfernen, indem Sie den Code so ändern, dass der Compiler ihn mag

Das ist ein Hindernis, denn dann gibt es zusätzliche Klammern. Aber niemand hindert die Liebhaber dieser Sache daran, zusätzliche Klammern zu setzen, und - was am wichtigsten ist - alle wären damit zufrieden

Ich bezweifle, dass es in Studio konfigurierbar ist - denn es gibt keine überflüssigen Warnungen über angeblich vergessene Klammern (zumindest standardmäßig) und daher gibt es kein Thema für die Konfiguration

 
A100:

Das stört mich nicht. Lassen Sie diese Warnungen einfach im alten MQL4 stehen.

So bleiben sie zum größten Teil

void OnStart()
 {
  int a=0,b=0,c=0,d=0,e=0,f=0;
  a=b|d/e^f|a^b&d^e%f|c;
 }

In µl4 wird auf alles geschimpft, in µl5 nur auf die Operationen << und >>, was durchaus logisch ist, denn ihre Überladungslogik wird sich meist stark von der Logik unterscheiden, auf deren Grundlage sie priorisiert wurden. Diese Warnungen haben mir schon oft geholfen oder mich zumindest nicht allzu sehr geärgert. Nun, und die logischen Operationen, die die Logik von && und || Code definieren, die ohnehin durch Klammern abgegrenzt werden sollten...

 
A100:

Ich bin auch kein Profi, aber ich habe mich mehr als einmal über solche Warnungen geärgert, weil ich zwischen Dutzenden (und manchmal Hunderten) solcher überflüssigen Warnungen die wirklich wichtigen und notwendigen verloren habe

Und es ist nicht klar, welche Warnungen Sie erhalten, wenn Sie überall Klammern setzen? Und wenn es um andere Fälle ging, muss man nicht alles über einen Kamm scheren.

In der Regel kommt es vor, dass man einen Zustand schnell korrigieren muss. Ich habe zum Beispiel einen Fehler in einer Bedingung gemacht, wo ich && an einer Stelle geschrieben habe und es durch || hätte ersetzen sollen. Ich habe es korrigiert und F7 gedrückt. Ich habe sofort eine Warnung erhalten. Ich schaue genau hin und sehe, dass das Ergebnis mit den aktuellen Änderungen nicht das ist, was ich erwartet habe. Ich habe es korrigiert - alles ist normal. Das heißt, der Compiler hat mir mit seiner Botschaft sehr geholfen.


Wenn Sie aber eine ganze Reihe von Warnungen haben, sollten Sie Ihren Code sorgfältiger schreiben. Oder bearbeiten Sie sie nicht aus Prinzip, um der Maschine zu beweisen, dass sie falsch liegt?

 
A100:

Es hindert Sie daran, weil es unnötige Klammern erzeugt. Aber das Setzen von zusätzlichen Klammern für Liebhaber dieses Geschäfts stört niemanden, und vor allem - jeder würde damit einverstanden sein

Ich bezweifle, dass es im Studio konfigurierbar ist - weil es keine zusätzlichen Warnungen über angeblich vergessene Klammern gibt (zumindest standardmäßig), so dass es kein Thema der Konfiguration ist

Völlig einverstanden. Da Sie sich selbst als Programmierer bezeichnen, seien Sie so nett und lernen Sie die Prioritäten der Operationen, erinnern Sie sich zumindest daran, dass es sie gibt. Ich wurde vor kurzem gebeten, einen Roboter hinzuzufügen, aber ich wurde gebeten, init() und start() hinzuzufügen, und als ich fragte, wann sie das geschrieben haben, wurde mir gesagt, dass das schon eine Woche her ist. Es gibt also einige "Coder" da draußen, aber es lohnt sich nicht, zusätzliche Warnungen für sie zu hinterlassen.

 
Vladimir Simakov:

Ich bin absolut einverstanden. Da Sie sich selbst als Programmierer bezeichnen, seien Sie so nett und lernen Sie die Prioritäten des Betriebs, erinnern Sie sich wenigstens daran, dass es sie gibt. Ich wurde vor kurzem gebeten, einen Roboter fertig zu schreiben, aber ich habe init() und start() dort, und als ich sie fragte, wann sie es geschrieben haben, wurde ihnen gesagt, dass es vor einer Woche war. Es gibt also immer noch "Coder", aber für diese Leute lohnt es sich nicht, unnötige Warnungen zu hinterlassen.

Die Kenntnis von Prioritäten hat nichts mit Warnungen zu tun. Ich schreibe im Stillen Code und bezeichne mich nicht als Programmierer.

 
A100:

Ich bezweifle, dass es im Studio eingerichtet ist.

Wir hatten bei einem unserer Projekte die eiserne Regel, dass alle Warnungen bei Release-Versionen behoben werden müssen, einschließlich einiger paranoider W4

https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017

Mir scheint - je mehr Warnungen, desto besser, wenn sie irgendwie gerechtfertigt sind und abgeschaltet werden können

 
fxsaber:

Wenn Sie eine große Anzahl von Warnungen haben, schreiben Sie den Code sorgfältiger. Oder korrigieren Sie sie nicht aus Prinzip, um zu beweisen, dass die Maschine falsch liegt?

Ich verwende meist C++-kompatiblen Code (und oft sogar nur eine einzige Datei). C++ hat sie nicht, und unnötige Klammern, wie hier bereits bemerkt, erschweren das Verständnis

1...34567891011121314151617...20
Neuer Kommentar