Fehler, Irrtümer, Fragen - Seite 706
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
1.
So erstellen Sie Arrays von Zeigern auf Strukturen (Arrays) und initialisieren sie anschließend for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. solide (gepackte) Arrays mit aussagekräftigen Daten zu speichern.
Wichtig bei der Datenausgabe in OpenCL-Rohpuffern (oder beim Senden an DLL, Schreiben in Dateien usw.)
Gleichzeitig ist es möglich, Datenzugriffe neu zu ordnen (z. B. beim Sortieren von Zeigern), ohne die Daten neu zu schreiben.
Eine Sprache mit sicherer Ausführung sollte keinen direkten Zugriff offenlegen/gewähren.
Klassen haben mehr Schutz und deshalb haben sie auch einen Griff.
Es wird keine Griffe für andere Objekte geben, da die Sicherheit wichtiger ist.
In OpenCL können beliebige Datentypen zur Übergabe von Daten verwendet werden, einschließlich Strukturen. Dort wird das void* verwendet. Bereiten Sie einfach einheitliche Daten im gewünschten Format vor und machen Sie sich an die Arbeit. Auf die Frage: "Ich will das nicht so machen, ich will es auf meine Art machen", würde ich antworten, dass das nicht geht - Sicherheit ist wichtiger.
1. Jeder Datentyp kann für die Datenübertragung in OpenCL verwendet werden, einschließlich Strukturen. Dort wird das void* verwendet. Bereiten Sie einfach einheitliche Daten im gewünschten Format vor und machen Sie sich an die Arbeit. In Erwartung der Frage "Ich will das nicht so machen, ich will es auf meine Art machen", werde ich antworten, dass das nicht geht - Sicherheit ist wichtiger.
2. eine Sprache mit sicherer Ausführung sollte keinen direkten Zugang offenlegen/gewähren.
Der Punkt ist, dass für alle Klassen, einschließlich der primitivsten, mql5 Compiler erstellt eine VMT, mit entsprechenden versteckten Feld in den Objekten (Zeiger auf VMT). Und dieser Zeiger in der rohen Puffer (Datei) ist zu viel für mich. Nicht nur, dass es Müll ist, der Platz wegnimmt, es bricht auch die Paketausrichtung in unangemessener Weise (OpenCL-Puffer haben 128-Bit-Ausrichtung). Das ist der Punkt. Klassen sind verlockend zu verwenden: Sie sind bequem, um mit mql zu arbeiten. Aber... siehe oben.
In Delphi gibt es ein gutes alternatives Beispiel für die Implementierung: VMT und dementsprechend erscheint der Zeiger auf VMT in den Klassen erst, nachdem die erste virtuelle Methode in der Klassenhierarchie auftaucht. Wäre es in mql5 genauso, wäre die Situation viel überschaubarer. Man könnte Klassen ohne virtuelle Methoden anstelle von Strukturen verwenden und es gäbe keine strukturschädigenden "Add-ons".
Nun bin ich auf eine Situation gestoßen, in der die Implementierung einer abstrakten (für die Vererbung bestimmten) Klasse, die ein Array von Strukturen kapselt, sich nicht für geerbte Dienste (z. B. Sortieren) eignet. Das Ersetzen eines Arrays von Strukturen durch ein Array von Klassen löst dieses Problem, schafft aber ein anderes.... (siehe oben).
Und ich verlange keinen "direkten Zugriff" und bin nicht an einer Adressarithmetik interessiert. Warum erschrecken Sie Kinder umsonst? :) mql5-Handle ist nicht einmal annähernd ein "roher" Zeiger. Und wenn dies (heimlich) der Fall ist - dann liegt die eigentliche Sicherheitslücke hier, nicht in der Implementierung von Handles (Pseudo-Zeigern) auf Benutzerdaten.
---
Im Moment sind Ihre Strukturen eigentlich Klassen ohne virtuelle Funktionen (bzw. VMT). Also gut, fügen Sie ihnen einfach einige Klassenmerkmale (Handles) hinzu. Dann brauchen Sie Zeiger auf Arrays auch nicht mehr so dringend (Sie können sie in Strukturen einpacken, wenn nötig).
Der Punkt ist nicht, dass ich es auf meine Weise machen möchte; der Punkt ist, dass für alle Klassen, einschließlich der primitivsten, mql5 Compiler VMT mit entsprechenden versteckten Feld in Objekten (Zeiger auf VMT) erstellt. Und dieser Zeiger in Rohpuffer (Datei) ist zu viel für mich. Nicht nur, dass es Müll ist, der Platz wegnimmt, es bricht auch die Paketausrichtung in einer völlig unangemessenen Weise (OpenCL-Puffer haben eine 128-Bit-Ausrichtung). Das ist der Punkt. Die Verwendung von Klassen ist verlockend: Sie sind bequem in mql zu verwenden. Aber... siehe oben.
In Delphi gibt es ein gutes alternatives Beispiel für die Implementierung: VMT und dementsprechend erscheint der Zeiger auf VMT in den Klassen erst, nachdem die erste virtuelle Methode in der Klassenhierarchie auftaucht. Wäre es in mql5 genauso, wäre die Situation viel überschaubarer. Man könnte Klassen ohne virtuelle Methoden anstelle von Strukturen verwenden und es gäbe keine strukturschädigenden "Add-ons".
Nun bin ich auf eine Situation gestoßen, in der die Implementierung einer abstrakten (für die Vererbung bestimmten) Klasse, die ein Array von Strukturen kapselt, sich nicht für geerbte Dienste (z. B. Sortieren) eignet. Das Ersetzen eines Arrays von Strukturen durch ein Array von Klassen löst dieses Problem, schafft aber ein anderes.... (siehe oben).
Und ich verlange keinen "direkten Zugriff" und bin nicht an einer Adressarithmetik interessiert. Warum erschrecken Sie Kinder umsonst? :) mql5-Handle ist nicht einmal annähernd ein "roher" Zeiger. Und wenn dies (heimlich) der Fall ist - so liegt die eigentliche Sicherheitslücke hier, aber nicht in der Implementierung von Handles (Pseudo-Zeigern) auf irgendwelche Benutzerdaten.
Sie wollen ein komplexes System mit abstrakten Daten aufbauen (was bereits eine Menge interner Metadaten und Beziehungen bedeutet) und es dann einer unkontrollierten OpenCL-Umgebung übergeben, wo es auf heikle Weise verändert werden kann. Deshalb erlauben wir nur einfachen Objekten und Arrays, frei zu operieren, ohne die Möglichkeit, virtuelle Tabellen zu überschreiben.
Sie fordern eigentlich indirekt einen direkten Zugang über die "Freiheit der abstrakten Konstruktionen". Dies ist ein Thema, das wir gut erforscht und aus Sicherheitsgründen architektonisch abgedeckt haben. Klassen in MQL5 leben nach ihren eigenen Regeln, wobei der Schwerpunkt auf der Sicherheit liegt. Andere Typen haben keine Griffe. Anstelle von Handles für einfache Typen und Strukturen können Sie Indizes in Arrays verwenden.
Die Griffe selbst in MQL5 sind korrekt (wachsen von einem), können Sie überprüfen.
1. Sie wollen ein komplexes System mit abstrakten Daten aufbauen (was bereits eine Menge interner Metadaten und Beziehungen bedeutet) und es dann einer unkontrollierten OpenCL-Umgebung übergeben, in der es auf clevere Weise verändert werden kann. aus diesem Grund erlauben wir nur einfachen Objekten und Arrays, frei zu operieren, ohne die Möglichkeit, virtuelle Tabellen zu überschreiben.
2. Sie fordern indirekt einen direkten Zugang über die "Freiheit der abstrakten Konstruktionen". Dieses Thema ist von uns gut recherchiert und architektonisch abgedeckt, um die Sicherheit zu gewährleisten. Klassen in MQL5 leben nach ihren eigenen Regeln, wobei der Schwerpunkt auf der Sicherheit liegt.
Handles in MQL5 sind korrekt (wächst von einem), können Sie es selbst überprüfen.
Ich möchte ausschließlich saubere Daten ohne Metadaten (Handles) in den Puffer übertragen. Ich brauche diese Metadaten nicht im Puffer. Sie sind dort nur im Weg. Und ich kann sie dort auch nicht ablegen - CLBufferWrite() lässt sie nicht hinein. Und das ist richtig.
2. ich bin eigentlich nicht für einen direkten Zugriff zu fragen, kann ich DLL für den direkten Zugriff verwenden (wenn ich es brauche).
aPointer = memcpy(a,a);
löst das Problem, einen Rohzeiger zu erhalten. Renat, versuchen Sie, das eigentliche Problem zu ergründen. Erfinde nichts, was nicht " wirklich" existiert. All das gibt es tatsächlich - ich habe es direkt und ohne Feinheiten in der Anfrage beschrieben. So konstruktiv wie möglich und mit vollem Verständnis für Sicherheitsfragen.
3. Das ist großartig.
--
Auf das dynamische Anlegen und Löschen von Strukturen (neu, löschen) sollten Sie ganz verzichten. Nicht einmal in irgendeiner Weise. Dann stellen sich auch die Sicherheitsprobleme nicht. Ich verstehe, was das Problem "eigentlich" ist (um es in Ihrer Sprache auszudrücken). Es gibt ein Problem der Definition des realen Typs für dynamische Objekte. Für Klassen wird es wahrscheinlich durch die Analyse eines Zeigers auf VMT gelöst. Aber: keine dynamischen Strukturen, kein Problem.
Denken Sie darüber nach: Was ist ein "Griff" in Bezug auf eine Einheit beliebigen Ausmaßes?
Sie können Handles für Objekte bereitstellen, deren Anzahl überschaubar ist (Klassen, Dateien usw.). Aber wenn Sie in einen Array-Bereich beliebiger Größe gehen, hat jeder Handle nur eine Chance, ein direkter Verweis auf ein Stück Speicher zu sein. Andernfalls wird die Zuordnungstabelle "Handle -> Speicher" sogar mehr Speicherplatz beanspruchen als die Entität, auf die verwiesen wird.
Und aufgrund der Sicherheitsbestimmungen können Sie keine Handles haben, die direkte Zeiger auf den Speicher sind. Deshalb gibt es auch keine Griffe für "jede unbegrenzte Einheit".
Renat:
1. Sie können Handles für eine überschaubare Anzahl von Objekten (Klassen, Dateien usw.) bereitstellen. Aber wenn Sie in einen Array-Bereich beliebiger Größe gehen, hat jeder Handle nur eine Chance, ein direkter Verweis auf ein Stück Speicher zu sein. Andernfalls wird die Handle -> Memory Mapping-Tabelle sogar mehr Speicher verbrauchen als die Entität, auf die verwiesen wird.
2. und aufgrund der Sicherheitsklausel können Sie keine Handles haben, die direkte Zeiger auf den Speicher sind. Deshalb gibt es auch keine Griffe für "jede unbegrenzte Einheit".
1. Konstruktiv zu sein ist eine gute Sache. Ich habe nachgedacht. Das Problem wurde genau im Zusammenhang mit massiven Strukturen aufgeworfen. Bei kleinen Strukturen ist die Kopierzeit ohnehin kurz. Ich denke, Probleme können hier nur durch Unvernunft des Benutzers entstehen, aber man kann den Speicher sowieso "dummerweise" vollstopfen ( z.B. mit Indikatorpuffern). Ich nehme nicht an, dass irgendjemand es vorzieht, ohne besonderen Bedarf mit Handles auf statischen Strukturen zu arbeiten. Und wenn man den Speicher überlaufen lässt, ist man selbst schuld. Machen Sie sich nicht so viele Gedanken über den volkstümlichen Unsinn, man kann ohnehin nicht alles verhindern (und auch nicht vorhersagen). :)
2. nein, nein. direkte Zeiger sind nicht notwendig, aber es würde nicht schaden, Handles zu haben, sogar "für jede unbeschränkte Entität". Das Wichtigste ist, dass es keine Verpflichtung gibt, sie zu benutzen, denn dann gibt es genug Speicherplatz für alle. :)
Ich verstehe nicht, worüber Sie sich hier aufregen. Wenn Sie Handles wollen, deklarieren Sie Ihre Strukturen als Klassen, das ist alles.
Wenn Sie direkten Zugriff auf den Speicher wünschen, schreiben Sie eine DLL.
Ich verstehe nicht, warum Sie sich hier das Genick brechen.
1. Sie wollen Handles, deklarieren Sie Ihre Strukturen als Klassen, das ist alles.
2. Wenn Sie direkten Zugriff auf den Speicher haben wollen, schreiben Sie eine DLL.
1) Das ist der Punkt: Es ist problematisch. Ich muss kein Array von Klassen in den Puffer schreiben (und das ist unmöglich). Ich muss dort Strukturen schreiben. Und ich will es schnell (ohne tatsächlich von Klassen in Strukturen umzuschreiben). Und für den geordneten Zugriff werden Griffe benötigt (für die Sortierung außerdem mit unterschiedlichen Schlüsseln).
Ein Ersatz könnte meine eigene Index-Tabelle sein - aber dann kann ich keine Klasse erstellen, die die Arbeit mit einem Array von Strukturen kapselt und die Fähigkeit hat, diese zu erben, zusammen mit einmal vorgeschriebenen Diensten (Sortierung und binäre Suche).
2. Ich will es nicht! !! !!! Hören Sie auf, mich auf der Stelle zu verteidigen! :))
Nein, wir werden solche Handlungen nicht vornehmen. Das ist das Böse schlechthin, für das wir bis zum Ende zur Rechenschaft gezogen werden.
Die ideale Lösung wären parametrisierbare Klassen
class MyClass<T> { T MyArray[]; .... };Aber darüber rede ich gar nicht mehr, vielleicht sollte ich es tun?