Fehler, Irrtümer, Fragen - Seite 1397

[Anatoli Kazharski]

Ilya Malev:

Und zweitens müssen wir diesen Indikatorpufferwert in anderen Indikatoren und Expert Advisors verwenden,

und etwas sagt mir, dass, wenn Sie einen Puffer für Berechnungen zu machen, wird es unmöglich sein, seinen Wert durch iCustom erhalten.

Ich weiß es übrigens nicht mehr genau, aber es scheint möglich zu sein. Probieren Sie es aus. )

[Ilya Malev]

Anatoli Kazharski:
Übrigens, ich weiß es nicht mehr genau, aber ich glaube, Sie können es. Probieren Sie es aus. )

Trotzdem habe ich ein Dutzend Indikatoren mit Attributen wie DRAW_NONE, die sich gegenseitig aufrufen, und dann brauche ich schon ein separates Subsystem, das die Messwerte aller funktionierenden Indikatoren nach Mauszeigerposition an einem Ort gruppiert. :)

[Anatoli Kazharski]

Ilya Malev:
Trotzdem habe ich ein Dutzend Indikatoren mit Attributen wie DRAW_NONE, die sich gegenseitig aufrufen, und dann brauche ich schon ein separates Subsystem, das die Messwerte aller funktionierenden Indikatoren nach Mauszeigerposition an einem Ort zusammenfasst. :)

Dieses Argument ist ernster zu nehmen. Wir könnten es in den Service Desk aufnehmen. ))

[Ilya Malev]

Wenn Sie Werte wie INDICATOR_CALCULATIONS über iCustom abrufen können, müssen Sie lediglich zulassen, dass diese Werte im Datenfenster angezeigt werden. Wenn ich von servicedesk eine Antwort auf meine Anfrage erhalte, werde ich diese Option vorschlagen.

[sigma7i]

A100:
Kompilierungsfehler:'a' - ist kein statisches Mitglied
aber das ist OK. Was ist der Unterschied?

//должен обращаться к функции, хотя бы потому что уж стоят скобки и тип, да еще a базового класса приватный
class A     { int a; };
class B : A { void a(); };
void B::a() {}
// здесь инлайнится, все правильно
class A     { int a; };
class B : A { void a() {} };
// так работает, видно проблема с компилятором
class A     {int h; void f(); };
class B : A {void a(); };
void B::a() {}

[sigma7i]

Ich weiß nicht, wie es Ihnen geht, aber ich sehe bereits mehrere Compilerfehler.

1) Es wird beim Vererben nicht zwischen Funktionen und Variablen unterschieden.

2) die Variable der Basisklasse ist privat, daher sollte zuerst die Meldung erscheinen, dass es unmöglich ist, auf private Mitglieder zuzugreifen

[Anatoli Kazharski]

sigma7i:

Ich weiß nicht, wie es Ihnen geht, aber ich sehe bereits mehrere Compilerfehler.

1) Es wird beim Vererben nicht zwischen Funktionen und Variablen unterschieden.

2) die Variable der Basisklasse ist privat, daher sollte zuerst die Meldung erscheinen, dass es unmöglich ist, auf die privaten Mitglieder zuzugreifen

Bitte nennen Sie einige Beispiele. Es wäre interessant zu sehen, in welchen Fällen derartige Probleme bei der Formatierung des Codes auftreten.

[sigma7i]

Anatoli Kazharski:
Nennen Sie mir einige Beispiele. Es ist interessant zu sehen, in welchen Fällen solche Probleme in Bezug auf die Codegestaltung auftreten.

Ich glaube, ich habe bereits Beispiele genannt. Aber ich werde es noch ausführlicher machen, damit es noch klarer wird:

Beachten Sie, dass ich im dritten Beispiel in Klasse A den Variablennamen durch "h" ersetzt habe und dieser Code kompilierbar ist (natürlich, wenn Sie die Beispiele 1 und 2 auskommentieren), was meine Vermutung bestätigt.

//+------------------------------------------------------------------+
//|                                                           ds.mq5 |
//|                        Copyright 2015, MetaQuotes Software Corp. |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2015, MetaQuotes Software Corp."
#property link      "https://www.mql5.com"
#property version   "1.00"
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+



//должен обращаться к функции, хотя бы потому что уж стоят скобки и тип, да еще a базового класса приватный
class A     { int a; };
class B : A { void a(); };
void B::a() {}
// здесь инлайнится, все правильно
class A     { int a; };
class B : A {void a() {} };
// так работает, видно проблема с компилятором
class A     {int h; void f(); };
class B : A {void a(); };
void B::a() {}


void OnStart()
  {
    // c объектами работает правильно
  
    B variable;
    variable.a();   // ошибка доступа, здесь все нормально
    variable.a = 1; // ошибка доступа, как и следовало ожидать, здесь все нормально
  }
//+------------------------------------------------------------------+

[Ilya Malev]

Situation: der Test ist auf H1 (ich denke, es ist wichtig - wir sprechen über einen Multi-Perioden-Test). Der letzte tägliche (D1) Bar in der Tester SeriesInfoInteger gibt zum Beispiel 2015.10.08. Ich nehme den iMA-Indikator auf D1 mit einem Offset von 2. Sie gibt den Wert für 2015.10.05 an (der 2015.10.06 mit einem Offset von 2 sein sollte).

Das bedeutet, dass der Indikator im Prüfgerät im Vergleich zur Erstellung der Zeitreihe verzögert wird. Dies geschieht eindeutig zu Beginn eines neuen D1-Balkens. Hat jemand eine solche Situation schon einmal erlebt? Ich werde das Beispiel noch nicht simulieren.

[[Gelöscht]]

Ilya Malev:

Situation: Der Test ist auf H1. Der letzte Tagesbalken (D1) im Tester SeriesInfoInteger gibt z.B. 2015.10.08. Ich nehme iMA-Indikator-Messwerte mit einem Offset von 2. Sie gibt den Wert für 2015.10.05 an (der 2015.10.06 mit einem Offset von 2 sein sollte).

Das bedeutet, dass der Indikator im Prüfgerät im Vergleich zur Konstruktion der Zeitreihe verzögert wird. Ist das schon einmal vorgekommen? Ich werde noch kein Beispiel simulieren.

Ja, das kann passieren, wenn man mit der TF arbeitet, die, soweit ich mich erinnere, nur älter ist als die aktuelle im Testgerät. Die Daten hatten nicht genug Zeit, um aktualisiert zu werden. D.h., wenn es sich um einen neuen Tag auf H1 handelt, ist der Vortag auf dem ersten Tick dieses neuen Tages auf D1.