Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 213

 
A100 #:

Und es besteht keine Notwendigkeit, das Verhalten bestehender Funktionen zu ändern - es genügt, neue korrekte Funktionen (mit einem Präfix/Suffix) hinzuzufügen und die bisherigen mit einer entsprechenden Warnung für veraltet zu erklären

Den ganzen Sinn von FileReadArray zerstören? Betrachten Sie diese Funktionen als eine Art Backup eines Speicherplatzes. Nur Bytes.

 
fxsaber #:

Den ganzen Sinn von FileReadArray zerstören? Betrachten Sie diese Funktionen als eine Art Backup eines Speicherplatzes. Nur Bytes.

Sie wollen sich also erst Schwierigkeiten durch private Konstanten schaffen und diese dann heldenhaft durch "direkten" Speicherzugriff überwinden?

Ich vertrete einen anderen Ansatz: Wenn eine solche Notwendigkeit besteht, bedeutet dies, dass das Programm von Anfang an falsch konzipiert wurde.

 
A100 #:

D.h. Sie schlagen vor, sich erst einmal selbst Schwierigkeiten zu machen, indem Sie private, verdeckte

Ich ziehe immer großen Nutzen aus den privaten/konst. Sie ermöglichen es Ihnen, die Architektur des Programms sehr gut zu kontrollieren.

und sie dann heldenhaft mit "direktem" Speicherzugriff zu überwinden?

Keine Überwindung. Alles ist sehr einfach und logisch.

Ich vertrete einen anderen Ansatz: Wenn ein solcher Bedarf entsteht, bedeutet dies, dass das Programm von Anfang an falsch konzipiert wurde.

Ich verstehe, dass sie bereit sind, alles in einen Heap zu schreiben (ohne private/const), wobei sie die Bequemlichkeit der architektonischen Kontrolle um der "Reinheit" von OOP willen aufgeben.

 
Ilyas #:

Die Akte... erschienen, als es noch keine Privatsphäre und keine Beständigkeit gab, dachten wir noch nicht daran, dieses Verhalten zu ändern, da wir es nicht als kritisch ansehen.

CharArray<->Struct erschien vor kurzem, aber sie funktionieren gut mit private/const. Hoffentlich werden sie nicht revidiert.

 
Um den Code sauber zu halten, sollten Serialisierungs- und Deserialisierungsmethoden für Strukturen geschrieben werden. Dann gibt es keinen Datenschutzkonflikt, und konstante Felder sind nicht konstant, wenn sie während der Deserialisierung geändert werden können
 
fxsaber #:

Ich verstehe, dass Sie bereit sind, alles in einen Heap zu schreiben (ohne private/const), und damit die Bequemlichkeit der architektonischen Kontrolle um der "Reinheit" von OOP willen aufgeben.

Sie missverstehen - aus Sicht der OOP ist das Objekt autark (es braucht keine externen Funktionen) - daher gibt es keinen Konflikt mit private. Und wenn es einen Konflikt mit const gibt, wie richtig festgestellt:

Sie sind es, die sie künstlich so gemacht haben
 
fxsaber #:

Ich verstehe, dass Sie bereit sind, alles in einen Heap zu schreiben (ohne private/const) und damit die Bequemlichkeit der architektonischen Kontrolle um der "reinen" OOP willen aufzugeben.

Sie sind bereit, aus Bequemlichkeit alle Schlupflöcher des direkten Speicherzugriffs zu nutzen, anstatt den weniger bequemen, aber sichereren kanonischen Ansatz zu verwenden.

 
TheXpert #:

Sie sind bereit, aus Bequemlichkeit alle Schlupflöcher des direkten Speicherzugriffs zu nutzen, anstatt den weniger bequemen, aber sichereren kanonischen Ansatz zu verwenden.

Zwei Anfragen:

  1. Zeigen Sie den Code zum Speichern und Laden der Struktur.
  2. Ein Beispiel für die Gefahren des nicht-kanonischen Ansatzes.
 

Nun, das ist ein heftiger Fehler. Beispiel:

class C{
   static uint count;
   const uint number;
public:
   C():number(++count){PrintFormat("C[%i]",number);}
  ~C(){PrintFormat("~C[%i]",number);}
   uint Number() const {return number;}
};
uint C::count=0;

void OnStart()
{
  C c[3]={};
  for(int i=0;i<ArraySize(c);Print(c[i++].Number()));
}
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]

Der Speicher wird zugewiesen, der Destruktor wird aufgerufen, wenn er freigegeben wird (was auf das erwartete Verhalten nach RAII hinweist), aber der Konstruktor wird vergessen, wenn das Objekt erstellt wird)))

 

Das habe ich noch nicht gesehen.