Fehler, Irrtümer, Fragen - Seite 1968

Neuer Kommentar
 

Warum diese alberne und nutzlose Warnung "no #import declaration", wenn man sie in die Header-Datei schreibt:

void f();
void f() {}

Es gibt keine Begrenzung für die Anzahl der Erklärungen an angemessenen Stellen. Ärgerlich, wenn ich eine kurze Beschreibung der verfügbaren Funktionen im mqh-Header haben möchte, muss ich Zeilen auskommentieren, was die Lesbarkeit negativ beeinflusst. Jemand könnte sagen, "packen Sie statische Methoden in eine Klasse oder Struktur (bei der Verwendung von Strukturen erscheint eine weitere wunderbare Warnung "struct has no members, size assigned to 1 byte")". Ich werde antworten: "Ich mag keine µl-Klassen, ich möchte die erste Option verwenden", ohne diese Flut von goopy-Warnungen. Warum zwingen Sie mich dazu, vollkommen gültige gängige Praktiken aufzugeben?

 
pavlick_:

Warum diese alberne und nutzlose "no #import declaration"-Warnung, wenn man sie in die Header-Datei schreibt:

Dies ist ein Sonderfall. Bei einer allgemeineren Lösung ist es sinnvoll, eine analoge

#pragma  warning (disable:xxxx)
und jeder erfahrene Programmierer kann die lästige Warnung abschalten (die Nummer ist im Befehls-Compiler zu finden). Das bestehende Warnsystem ist im Wesentlichen nutzlos... Ich schaue sie mir gar nicht erst an, weil es Hunderte von gleichartigen Texten gibt, die den Schreibstil und die Erfahrung des Programmierers nicht berücksichtigen. Und unter diesen Hunderten von Warnungen ist es schwer, wirklich wichtige Warnungen zu finden, die es wert sind, beachtet zu werden
  
class A {
public:
        A() { Print( A::a ); } //Результат: 0
        static const int a;
};
/*
...
*/
const int A::a = 1;
Sie glauben mir nicht? Ich werde morgen versuchen, den Code hinzuzufügen.
 
A100:

Dies ist ein Sonderfall. Bei einer allgemeineren Lösung ist es sinnvoll, eine analoge

und jeder erfahrene Programmierer kann lästige Warnungen abschalten (die Nummer ist im Befehl Compiler zu finden). Das bestehende Warnsystem ist im Wesentlichen nutzlos... Ich schaue sie mir gar nicht erst an, weil es Hunderte von Warnungen der gleichen Art gibt, die den Schreibstil und die Erfahrung des Programmierers nicht berücksichtigen. Und unter diesen Hunderten von Informationen ist es schwer, wirklich wichtige Informationen zu finden, die es wert sind, beachtet zu werden
Ja, ich stimme zu. Aber ich denke, es ist besser, wenn Sie eine ganze Reihe von Warnungen auf einmal verwalten. Ein Schlüsselmechanismus (wie -Wno_all) oder #pragma warning (level:{0|1|2|...}). Es ist mühsam, eine nach der anderen zu deaktivieren.
 

Liebe Entwickler! Erinnern Sie sich bitte daran, ob die Tatsache bearbeitet wurde, dass, wenn sich die Indikatorberechnung in einem Unterfenster befindet und der Stil mehrerer seiner Puffer DRAW_NONE ist, sie die Skala der Anzeige im Unterfenster nicht beeinflussen? Oder gab es keine solchen Bearbeitungen?

Wenn wir diese Änderungen noch nicht vorgenommen haben, sollten wir sie vornehmen. Denn jetzt stellt sich heraus, daß der Stil DRAW_NONE die Grafiken im Unterfenster beeinflußt, die einen völlig anderen Maßstab haben sollten!

 
pavlick_:
Ja, ich stimme zu. Ich denke nur, dass es besser ist, eine Reihe von Warnungen auf einmal zu verwalten. Schlüsselmechanismus (wie -Wno_all) oder #pragma warning (level:{0|1|2|...}). Es ist mühsam, eine nach der anderen zu deaktivieren.

Ich fordere wahrscheinlich schon seit Jahren für jede Warnung und jeden Fehler ein Beispiel, aus dem klar hervorgeht, warum sie auftreten.

Vor diesem Hintergrund erscheinen die Staffelung und die ausdrückliche Kontrolle von Optionsscheinen wie ein Hirngespinst.

 
Alexey Kozitsyn:

Liebe Entwickler! Erinnern Sie sich bitte daran, ob die Tatsache bearbeitet wurde, dass, wenn sich die Indikatorberechnung in einem Unterfenster befindet und der Stil mehrerer seiner Puffer DRAW_NONE ist, sie die Skala der Anzeige im Unterfenster nicht beeinflussen? Oder gab es keine solchen Bearbeitungen?

Wenn wir diese Änderungen noch nicht vorgenommen haben, sollten wir sie vornehmen. Andernfalls stellt sich nun heraus, daß der Stil DRAW_NONE die Grafiken im Unterfenster beeinflußt, die einen völlig anderen Maßstab haben sollten!

Dies wurde behoben. Ich habe einen Strafzettel geschrieben und dann überprüft...

Nachtrag: Es stellte sich heraus, dass es sogar 2 Tickets gab. In MT4 wurde das Problem behoben, aber in MT5 anscheinend nicht.

 
Stanislav Korotky:

Dies wurde behoben. Ich habe einen Strafzettel geschrieben und dann kontrolliert.

Ich dachte, das sei behoben, aber jetzt ist es nicht mehr so. Ich habe es gerade überprüft. Bild 1643.
 
Alexey Kozitsyn:
Ich dachte, das Problem sei behoben, aber das ist es jetzt nicht mehr. Gerade überprüft. Bild 1643.

Siehe oben, ich bin fertig ;-)

 
Stanislav Korotky:

Siehe oben, ich bin fertig ;-)

Ja, ich verstehe... dann werde ich eine weitere Anwendung erstellen.
1...196119621963196419651966196719681969197019711972197319741975...3184
Neuer Kommentar