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.
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.
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
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:
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.
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:
Zeigen Sie den Code zum Speichern und Laden der Struktur.
Ein Beispiel für die Gefahren des nicht-kanonischen Ansatzes.
2021.11.1816:03:31.424 test (EURUSD,M1) 02021.11.1816:03:31.424 test (EURUSD,M1) 02021.11.1816:03:31.424 test (EURUSD,M1) 02021.11.1816:03:31.424 test (EURUSD,M1) ~C[0]
2021.11.1816:03:31.424 test (EURUSD,M1) ~C[0]
2021.11.1816: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)))
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.
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.
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.
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.
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:
Für weitere Informationen über das Handelsforum, automatisierte Handelssysteme und das Testen von Handelsstrategien
Eigenheiten von mql5, Tipps und Tricks
Ilyas, 2021.11.17 21:45
konstante Felder bedeutet nicht konstantIch 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.
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:
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())); }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)))
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Eigenheiten von mql5, Tipps und Tricks
Vladimir Simakov, 2021.11.18 14:11
Das habe ich noch nicht gesehen.