Fehler, Irrtümer, Fragen - Seite 2670

Neuer Kommentar
 

Testerfehler (oder vielleicht verstehe ich es nicht mehr)

Profit-Trade fehlt im Testgerät

 

Eine weitere Begegnung mit dem zuvor beschriebenen Fehler- "Undefiniertes Verhalten, Sie erstellen ein komplexes umhülltes Objekt mit internem Typ "C" mehrmals, aber es stellt sich heraus, dass es ein völlig anderer Datentyp ist, vielleicht "B", vielleicht "int", was immer Sie wollen...".
Tatsächlich dauerte es einen Tag, um das Problem zu lokalisieren, zu reproduzieren und Abhilfemaßnahmen zu finden, leider ohne Erfolg...
Derzuvor vorgeschlagene Workaround mit fiktiven Template-Parametern für das unten stehende Beispiel hat sich als nicht praktikabel erwiesen.

template<typename _Tp, typename _Opt>
struct It_g{
   class Opt : public _Opt{}; 
   _Tp p;
};

template<typename _Tp>
class A_g{
public:
   struct It : public It_g<_Tp, Opt_g<_Tp>>{};
};

template<typename _Tp>
class V{
public:
   struct It : public  A_g<_Tp>::It{};
   It b;
};

template<typename _Tp>
class Opt_g{
   template<typename _It>
   static void test(_It &it){      
      printf(typename(_Tp));          // int
      printf(typename(it.p));         // ClassA*
      
      _Tp p = it.p;                   // Compiler Error: '=' - illegal operation use
   };
};


template<typename T>
class GetStructType{
public:
   struct type : public T{};
};

template<typename _It>
void test(_It &it){
   GetStructType<_It>::type::Opt::test(it);
}

class ClassA{};


void OnStart(){ 
   V<int> v1;
   test(v1.b);
   
   V<ClassA*> v2;
   test(v2.b);
   
   V<int>::It it3;
   test(it3);
   
   V<ClassA*>::It it4;
   test(it4);
}

Die einzige praktikable Lösung, die ich mit dem "hausgemachten" Auto-Typ zu bekommen, aber ich habe riesige Kompilierungskosten mit Null Gewinn in der Geschwindigkeit des realen Code...
Bitte helfen Sie, vielleicht hat jemand eine Idee, wie man das Problem umgehen kann.

 
Alexey Klenov:

Testerfehler (oder vielleicht verstehe ich es nicht mehr)

Der Visualisierer zeigt aus architektonischen Gründen nicht immer den aktuellen Status an.

 
fxsaber:

Der Visualisierer zeigt aus architektonischen Gründen nicht immer den tatsächlichen Zustand.

Danke, das werde ich im Hinterkopf behalten.
 

Defekte im Template-Funktions-/Klassen-Cache:
(nicht behoben durch MT5(build 2361)) *** (up) Undefiniertes Verhalten, Sie erstellen ein komplexes umhülltes Objekt mit internem Typ "C" mehrmals und es stellt sich heraus, dass es ein ganz anderer Datentyp ist, vielleicht "B", vielleicht "int", was immer Sie wollen...
(nicht behoben durch MT5(build 2361)) * Kompilierfehler, Fehler bei der Übergabe eines Funktionszeigers als const ref Template-Argument.
(nicht behoben durch MT5(build 2361)) * Kompilierfehler, B<int> Objekt kann nach B<void*> Klassenobjekt erstellt werden, aber Kompilierfehler tritt auf, wenn es vorher gemacht wird.


Defekte in der Arbeit mit Vorlagenfunktionen/Klassen:
(nicht behoben durch MT5(build 2361)) *** (up) Kompilierfehler, Fehler in Template-Funktion, übergebener Zeiger innerhalbexpliziter Typkonvertierungsoperation verhält sich sonst wie eine Klasse.
(nicht behoben durch MT5(build 2361)) ** Kompilierfehler, Fehler bei der Generierung des Codes von Template-Klassen, wenn eine interne Klasse verwendet wird.
(nicht behoben in MT5(build 2361)) ** Kompilierfehler, Fehler beim Versuch, auf eine interne Klasse für einen Template-Parameter einer Template-Funktion zuzugreifen.
(nicht behoben durch MT5(build 2361)) ** Kompilierfehler, Fehler bei der Generierung von Template-Methoden/Klassen, der Prozess der "automatischen Ersetzung" von Template-Parametern geht außerhalb des Scops in den Hauptprogrammcode.
(nicht behoben durch MT5(build 2361)) * Kompilierfehler, Fehler bei der Generierung von fehlendem Template-Klassen-Code, wenn die Template-Klasse als Rückgabewert für eine Template-Methode fungiert.
(nicht behoben durch MT5(build 2361)) * Kompilierfehler, Fehler, wenn eine interne Struktur an eine Template-Funktion übergeben wird, kann der resultierendeDatentyp nicht als Basisdatentyp für eine andere interne Struktur in der Template-Klasse verwendet werden.
(nicht behoben durch MT5(build 2361)) * Kompilierfehler, Fehler beim Aufruf einer Template-Funktion mit expliziten Argumenttypen, wenn diese von einer überladenen Nicht-Template-Funktion aufgerufen wird.
(nicht behoben durch MT5(build 2361)) Kompilierfehler, Fehler bei interner Klassendefinition - kein Verweis auf globalen Namespace bei Angabe einer Basisklasse.
(nicht behoben durch MT5(build 2361)) *** (neu) Compile Error, der Hauptanspruch auf die unangemessene Ausgabe Warnung - "veraltetes Verhalten, versteckte Methodenaufrufe werden in einer zukünftigen MQL-Compiler-Version deaktiviert werden".Die aktuelle Implementierung ist das Abfeuern einer Kanone über einen Spatzen.
(nicht behoben durch MT5(build 2361)) ** (neuer) Kompilierfehler, der Fehler betrifft den Rückgabewert einer Template-Funktion, wenn der Rückgabewert eine interne Klasse innerhalb einer Template-Klasse ist, deren Parametertyp durch den Argumenttyp der Template-Funktion definiert ist.
(nicht behoben durch MT5(build 2361)) * (neu)Kompilierfehler, bei der Deklaration einer Template-Funktion innerhalb einer Template-Klasse wird keine Prüfung auf wiederverwendete Template-Typ-Namen durchgeführt, was zu unerwartetem Verhalten führt.
(nicht behoben durch MT5(build 2361)) * (neu) Runtimer Fehler, im Basisklassenkonstruktor ist es unmöglich, einen expliziten Typecast beim Casting eines Zeigers auf ein Objekt der Basisklasse in einen Zeiger auf die Elternklasse durchzuführen.
(nicht behoben durch MT5(build 2361)) (neu) Kompilierfehler, mehrere Defekte im Zusammenhang mit der Rückgabe eines "an Ort und Stelle erstellten" Objekts, wenn die Vorlagenklasse/-struktur ein Objekt ist.


Defekte im Zusammenhang mit falscher Aufrufpriorität für überladene Funktionen in MQL vs. C++:
(nicht behoben durch MT5(build 2361)) *** Wenn es eine Vererbung von Klassen A <= B <= C <= D gibt und zwei Überladungsfunktionen implementiert sind, z.B. eine mit dem Parameter A* und die zweite mit dem Parameter B*, dann führt die Übergabe einer solchen Funktion an ein Objekt C* oder D* in MQL zu einem Kompilierungsfehler "ambiguous call to overloaded function".
(nicht behoben durch MT5(build 2361)) ** Laufzeit, Prioritätsfehlanpassung bei Aufrufen von überladenen Template-Funktionen.
(nicht behoben durch MT5(build 2361)) ** Kompilierfehler, die Priorität von Aufrufen überladener Template-Funktionen hängt tatsächlich vom Typ des Template-Parameters ab, was theoretisch das Ergebnis der Kompilierung nicht beeinflussen sollte.
(nicht behoben durch MT5(build 2361)) ** Obwohl es eine überladene Template-Funktion mit einer passenden Signatur für die übergebenen Parameter gibt, tritt ein Kompilierungsfehler bei der Generierung des Codes der Template-Funktion auf.


Defekte im Zusammenhang mit der langsamen Ausführung von Funktionen, Code-Optimierungsarbeiten:
(nicht behoben durch MT5(build 2361)) ** (neu) Laufzeit, großer Overhead beim Hinzufügen von einem Element nach dem anderen in ein Array mit ArrayResize, trotz der Tatsache, dass der Speicher für sie im Voraus reserviert wurde, zum Beispiel sind Strukturen bis zu 7 mal langsamer.


Vorschläge:
link- darüber, dass Literale und temporäre Variablen als const ref Funktionsargumente übergeben werden können.
Link- beimVerschieben von Projektdateien in der Registerkarte "Projekt", für verschobene Dateien, die geöffnet sind und sich in ME-Registerkarten befinden, um ihren Speicherpfad automatisch zu aktualisieren.
link- zur Einführung der Funktionalität der Typdeklaration in MQL.
link- über die Möglichkeit, die Erzeugung von Standard-Kopierkonstruktoren und Zuweisungsoperatoren zu erzwingen.

 
fxsaber:

Der Visualisierer zeigt aus architektonischen Gründen nicht immer den aktuellen Status an.

Alexey Klenov:
Danke, ich werde es im Hinterkopf behalten.

Abhilfe durch Ausführen einiger Ticks (F12) nach dem Pausieren.

 
Andrey Khatimlianskii:

Abhilfe durch Ausführen einiger Ticks (F12) nach dem Pausieren.

Ich danke Ihnen. Ich werde es ausprobieren.

 
Sergey Dzyublik:

Eine weitere Begegnung mit dem zuvor beschriebenen Fehler- "Undefiniertes Verhalten, Sie erstellen ein komplexes umhülltes Objekt mit internem Typ "C" mehrmals, aber es stellt sich heraus, dass es ein völlig anderer Datentyp ist, vielleicht "B", vielleicht "int", was immer Sie wollen...".
Tatsächlich dauerte es einen Tag, um das Problem zu lokalisieren, zu reproduzieren und Abhilfen zu finden, leider alles ohne Erfolg...

Schließlich gelang es mir, eine akzeptable Lösung zu finden.
Es stellt sich heraus, dass die Verwendung eines statischen Klassenmitglieds eine Möglichkeit bietet, den oben beschriebenen Fehler zu umgehen:

template<typename _Tp, typename _Opt>
struct It_g{
   class Opt : public _Opt{}; 
   _Tp p;
   
   static Opt opt;
};

template<typename _Tp, typename _Opt>
static It_g::Opt It_g::opt;


template<typename _Tp>
class A_g{
public:
   struct It : public It_g<_Tp, Opt_g<_Tp>>{};
};

template<typename _Tp>
class V{
public:
   struct It : public  A_g<_Tp>::It{};
   It b;
};


template<typename _Tp>
class Opt_g{
   template<typename _It>
   static void test(_It &it){      
      printf(typename(_Tp));          // ClassA*
      printf(typename(it.p));         // ClassA*
      
      _Tp p = it.p;                   // OK
   };
};


template<typename _It>
void test(_It &it){
   it.opt.test(it);
}

class ClassA{};


void OnStart(){ 
   V<int> v1;
   test(v1.b);
   
   V<ClassA*> v2;
   test(v2.b);
   
   V<int>::It it3;
   test(it3);
   
   V<ClassA*>::It it4;
   test(it4);
}
 

Wie kann ich diesen Speicherfehler beheben?


Nach und nach weigert er sich, mehr und mehr Dateien zu speichern. Bald werden alle gespeicherten Daten nicht mehr aktualisiert werden können.

 

Die Gewinne/Verluste im Tooltip für Buy-Stop-Limit-Orders und für Sell-Stop-Limit-Orders werden falsch berechnet.

Wenn Sie mit der Maus über tp fahren

wenn Sie mit der Maus über das Symbol sl

1...266326642665266626672668266926702671267226732674267526762677...3184
Neuer Kommentar