Fehler, Irrtümer, Fragen - Seite 2564

Neuer Kommentar
 
Igor Makanu:

?

es ist eine merkwürdige situation, alles außerhalb der klasse hat lange Zeit mit den staichiqs funktioniert. und ich mache gerade ein großes aufhebens darum.... Reproduzieren Sie den Code doch einfach mal selbst:

Siehst du eine Objektinstanz? und es existiert in MQL ;)

SZZ: Und es gibt sie auf der Ebene der Hilfe ... was ist dein Problem mit mir?

https://www.mql5.com/ru/docs/basis/oop/staticmembers

pr


imp

 
Andrey Barinov:

Für statische Objekte gelten dieselben Regeln (private, protected, public), sie müssen nur nicht erstellt werden.

Nicht im Allgemeinen: Eine öffentliche Statistik kann beispielsweise nicht in einer abgeleiteten Klasse eingeschränkt werden.

 
Andrey Barinov:



Hmmm... Wie kann man die Absurdität der Situation erklären... Ich habe Ihnen vorgeschlagen, die Beiträge der Admins (Entwickler) zu lesen, ich habe Ihnen die Hilfe gezeigt, die sie geschrieben haben, was wollen Sie von mir mit Ihren Bildern?

Ich glaube nicht, warum es so ist, ich lese das Forum und Hilfe, und tun, wie von den Entwicklern empfohlen. Wenn Sie es für notwendig halten, schreiben Sie an den "Ausschuss zum Schutz der C++-Standards", an die UN... Nun, zumindest der Administrator in der PM, wenn schwach, aber dann sperren Sie die Entwickler Nachrichten und erhalten Sie Ihren Weg!

ZS: Ich habe es irgendwie geschafft, den Quellcode einzufügen und nicht die Bilder, warum hast du das nicht getan?

int print(int value)
{  Print(value,":",__FUNCTION__); 
 return(value);
}
class A
{
private:
   static int        a1;
   static void       inc_a1(){a1++; Print("a1 = ", a1);}
protected:
   static int        a2;
public:
   static int        a3;

};
//+------------------------------------------------------------------+
static int A::a1 = print(1);
static int A::a2 = print(2);
static int A::a3 = print(3);

//+------------------------------------------------------------------+
void OnStart()
{

A::inc_a1();
A::inc_a1();
A::inc_a1();

}

2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4

ZS: die Situation ist ziemlich komisch, ich wollte helfen, jetzt mache ich Ausreden.... Warum? - Nun, die Wahrheit auf die Schiene setzen... auf die Harke treten....
 
Igor Makanu:

Der einzige Fehler im Code liegt im Zugriff auf die private Methode. Dieser Fehler ist vor kurzem aufgetreten.

 

Die Funktion ChartOpen gibt im Dienst immer 0 zurück. Obwohl sich die Karte selbst öffnet.

#property service

//int OnInit()
void OnStart()
  {
   long Otvet= ChartOpen(Symbol(),PERIOD_D1);
   Print("Otvet=",Otvet);

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

Der einzige Fehler im Code liegt im Zugriff auf die private Methode. Dieser Fehler ist vor kurzem aufgetreten.

Ich dachte, ich hätte etwas vergessen, also habe ich nachgelesen, wie sich Statik in C# verhälthttps://metanit.com/sharp/tutorial/3.6.php

Statische Klassenmitglieder sind für alle Objekte der Klasse gleich, daher müssen Sie sich auf sie mit ihrem Klassennamen beziehen:

Beachten Sie, dass sich statische Methoden nur auf statische Klassenmitglieder beziehen können. Wir können keine nicht-statischen Methoden, Felder oder Eigenschaften innerhalb einer statischen Methode ansprechen.


In MQL wird die Statik vor der Ausführung von OnInit() initialisiert, jetzt wollen wir die globale Sichtbarkeit von privaten Methoden für die Statik diskutieren: .... dieses Verhalten der Statik in MQL - wenn Sie Statik verwenden, bedeutet das, dass wir die Datenschutzfunktionen einer Klasse nicht nutzen, imho

wie groß ist der Fehler? - Ich habe geschrieben, dass das Verhalten bei der Verwendung einer Kontextoperation vom Programmierer bestimmt wird (der Kontextauflösungsoperator ist der Operator mit der höchsten Priorität in der Sprache! ), und der Compiler wird richtig helfen - nun, wie es geschieht)))

Funktioniert das so?

class A
  {
private:
   static void              My_function()
     {
      Print("^_^");
     }
  };
  
A a;
void OnStart()
  {
   A::My_function();
   a.My_function();  // 'A::My_function' - cannot access private member function        
  }

im Großen und Ganzen erfüllt er seine Aufgabe


PS: aktualisiert auf 2145 - Code mit Statik verhält sich genauso, wenn es ein halbes Jahr so bleibt, wird sich herausstellen, dass dies das geplante Verhalten der Statik ist ;)

UPD: Vergessen Sie nicht, dass dies im Jargon als "schmutzige Tricks" bezeichnet wird! ))) - Suchen Sie im Internet nach vielen Beispielen, wo dieses Verhalten als Sprachstandard akzeptiert wird und wo es an einen bestimmten Compiler des Herstellers gebunden ist. Bricht eval() in Python nicht effektiv die lineare Codeausführung? - Nun, manche tun es, manche nicht, weil das Verhalten unvorhersehbar ist.


UPD: siehe auf 2145 meine Frage von vor einem Monathttps://www.mql5.com/ru/forum/320733#comment_12989063

https://www.mql5.com/ru/forum/320733#comment_12958594

void OnStart()
  {
   double x=100.0;
   f(x);
  }
//_______________________________________________________________________
void f(bool v)
  {
  }
//_______________________________________________________________________

es hat sich nichts geändert, bei einer bool-Typ-Prüfung hat der Compiler nicht gelernt, Warnungen zu schreiben - das ist sehr unangenehm, ich habe nach einem Fehler in meinem Code gesucht, obwohl ich sicher war, dass der MQL-Compiler immer auf Typübereinstimmung prüft

 
Igor Makanu:

Inwieweit ist das ein Fehler? - Wie auch immer die Entwickler es drehen und wenden, so wird es sein.

Es ist offensichtlich, dass der Fehler behoben werden wird.

Es hat sich nichts geändert, der Compiler hat nicht gelernt, wie man bei der Überprüfung von Typen Warnungen für bool schreibt

Die automatische Umwandlung von Zeigern und numerischen Typen in bool ist sehr praktisch.

 
Igor Makanu:

nichts hat sich geändert, auf bool bei der Überprüfung von Typen der Compiler hat nicht gelernt, Warnungen zu schreiben - das ist sehr unangenehm, ich war schon auf der Suche nach einem Fehler in meinem Code, obwohl ich sicher war, dass MQL-Compiler immer streng überwacht Typ-Matching

Bei diesem Casting gehen keine Daten verloren. Entweder 0 oder nicht 0.

Ein anderer Fall ist, wenn double -> ein beliebiger Integer-Typ (bis einschließlich int32)

 
Slava:

Bei diesem Casting gibt es keinen Datenverlust. Entweder 0 oder nicht 0.

Eine andere Sache ist, wenn man double -> irgendeinen Integer-Typ (bis zu und einschließlich int32) castet

aber andersherum?

Ich habe nach einem Fehler in meinem Code gesucht

Zuerst habe ich einen Test geschrieben, aber zuerst int verwendet, dann habe ich aufgegeben, bool zu verwenden, aber ich habe nicht den ganzen Code repariert, ich erinnere mich nicht, aber es war so:

void OnStart()
{  int x=100.0;
   f(x); }
//_______________________________________________________________________
void f(int  v)  //так тестил
{
   if(v>0) v++;

}

//_______________________________________________________________________
void f(bool  v)  // потом решил, что мне нужен флаг, а ниже забыл исправить код
{
   if(v>0) v++;

}
//_______________________________________________________________________


Ich bin irgendwie bereit für ein solches Verhalten jetzt, aber warum schreibe ich darüber... gut, bei der Überprüfung von MQL-Bedingungen in if() - tut es streng Kontrolle Typen? jede Verwendung von nicht-booleschen Operationen wird eine Warnung ausgeben? - Nun, auf die gleiche Weise schrieb ich in C# in VS2017 - mein Beispielcode wird nicht kompilieren und MQL wird nicht eine Warnung werfen. Meiner Meinung nach birgt ein solches Verhalten für diejenigen, die neu in der Programmierung in MQL sind, einige Überraschungen.

 
fxsaber:

Es ist offensichtlich, dass der Fehler behoben werden wird.

Ich werde nicht streiten, aber meine Meinung ist, dass man sich nicht auf die Kontrolle des Compilers verlassen sollte, wenn man die Klasse über die Statik sowie über den Kontextauflösungsoperator verlässt,

d.h. wenn Sie eine statische Methode/ein statisches Feld schreiben oder ::: verwenden - verlassen Sie sich nicht auf den Compiler

1...255725582559256025612562256325642565256625672568256925702571...3184
Neuer Kommentar
Grund der Beschwerde: