Erreurs, bugs, questions - page 706
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
1.
Pour créer des tableaux de pointeurs vers des structures (tableaux) et les initialiser ensuite for(i){ S[i] = GetPointer(StaticStruct[i]) ; }
2. conserver des tableaux solides (emballés) de données significatives.
Important lorsqu'il s'agit de la sortie de données vers des tampons bruts OpenCL (ou l'envoi vers une DLL, l'écriture dans des fichiers, etc.)
En même temps, il est possible de réorganiser les accès aux données (par exemple, lors du tri des pointeurs) sans réécrire les données.
Un langage dont l'exécution est sécurisée ne doit pas exposer/donner un accès direct.
Les classes ont plus de protections et c'est pourquoi elles ont une poignée.
Il n'y aura pas de poignées pour d'autres objets, la sécurité étant plus importante.
Dans OpenCL, tous les types de données peuvent être utilisés pour transmettre des données, y compris les structures. Le void* y est utilisé. Il suffit de préparer des données uniformes dans le format requis et de se mettre au travail. Anticipant la question "Je ne veux pas le faire de cette façon, je veux le faire à ma façon", je répondrais que vous ne pouvez pas le faire - la sécurité est plus importante.
1. Tout type de données peut être utilisé pour le transfert de données dans OpenCL, y compris les structures. Le void* y est utilisé. Il suffit de préparer des données uniformes dans le format requis et de se mettre au travail. Anticipant la question "Je ne veux pas le faire de cette façon, je veux le faire à ma façon", je répondrai que vous ne pouvez pas le faire - la sécurité est plus importante.
2. un langage à exécution sécurisée ne doit pas exposer/donner un accès direct.
Le fait est que pour toutes les classes, y compris les plus primitives, le compilateur mql5 crée des VMT, avec le champ caché correspondant dans les objets (pointeur vers VMT). Et ce pointeur dans le tampon brut (fichier) est trop pour moi. Non seulement c'est un déchet qui prend de l'espace, mais il casse aussi l'alignement des paquets de manière inappropriée (les tampons OpenCL ont un alignement de 128 bits). C'est le point. Il est tentant d'utiliser les classes : elles sont pratiques pour travailler avec mql. Mais... voir ci-dessus.
Dans Delphi, il existe un bon exemple d'implémentation alternative. VMT et, par conséquent, les pointeurs vers VMT n' apparaissent dans les classes qu'après l'apparition de la première méthode virtuelle dans la hiérarchie de la classe. Si c'était la même chose dans mql5, la situation serait beaucoup plus facile à gérer. On pourrait utiliser des classes sans méthodes virtuelles au lieu de structures et il n'y aurait pas de "compléments" nuisibles à la structure.
J'ai rencontré une situation où l'implémentation d'une classe abstraite (destinée à l'héritage) encapsulant un tableau de structures ne se prête pas aux services hérités (comme le tri). Remplacer un tableau de structures par un tableau de classes résout ce problème, mais crée un autre..... (voir ci-dessus).
Et je ne demande aucun "accès direct" et je ne suis pas intéressé par une quelconque arithmétique d'adresse. Pourquoi effrayer les enfants pour rien ? :) La poignée mql5 n'est même pas proche d'un pointeur "brut". Et s'il l'est (subrepticement), alors la véritable faille de sécurité se situe ici, et non dans la mise en œuvre de poignées (pseudo-pointeurs) vers des données utilisateur.
---
Pour l'instant, vos structures sont en fait des classes sans fonctions virtuelles (et VMT, respectivement). Il suffit donc de leur ajouter des caractéristiques de classe (handles). Dans ce cas, vous n'aurez pas non plus besoin de pointeurs sur les tableaux (vous pourrez les intégrer dans des structures si nécessaire).
Le problème n'est pas que je veuille le faire à ma façon ; le problème est que pour toutes les classes, y compris les plus primitives, le compilateur mql5 crée un VMT avec le champ caché correspondant dans les objets (pointeur vers le VMT). Et ce pointeur dans un tampon brut (fichier) est trop pour moi. Non seulement c'est un déchet qui prend de l'espace, mais cela casse aussi l'alignement des paquets d'une manière complètement inappropriée (les tampons OpenCL ont un alignement de 128 bits). C'est le problème. Utiliser les classes est tentant : elles sont pratiques à utiliser dans mql. Mais... voir ci-dessus.
Dans Delphi, il existe un bon exemple alternatif d'implémentation. VMT et, par conséquent, le pointeur vers VMT n' apparaît dans les classes qu'après l'apparition de la première méthode virtuelle dans la hiérarchie des classes. S'il en était de même dans mql5, la situation serait beaucoup plus gérable. On pourrait utiliser des classes sans méthodes virtuelles au lieu de structures et il n'y aurait pas de "compléments" nuisibles à la structure.
J'ai rencontré une situation où l'implémentation d'une classe abstraite (destinée à l'héritage) encapsulant un tableau de structures ne se prête pas aux services hérités (comme le tri). Remplacer un tableau de structures par un tableau de classes résout ce problème, mais crée un autre..... (voir ci-dessus).
Et je ne demande aucun "accès direct" et je ne suis pas intéressé par une quelconque arithmétique d'adresse. Pourquoi effrayer les enfants pour rien ? :) La poignée mql5 n'est même pas proche d'un pointeur "brut". Et s'il l'est (subrepticement) - alors la véritable faille de sécurité se trouve ici, mais pas dans la mise en œuvre des poignées (pseudo-pointeurs) vers les données de l'utilisateur.
Vous voulez construire un système complexe avec des données abstraites (ce qui signifie déjà beaucoup de métadonnées et de relations internes), puis le confier à un environnement OpenCL non contrôlé où il peut être modifié de manière délicate. C'est pourquoi nous ne permettons qu'aux objets et aux tableaux simples de fonctionner librement sans pouvoir écraser les tables virtuelles.
En fait, vous demandez indirectement un accès direct via la "liberté des constructions abstraites". Il s'agit d'un sujet que nous avons bien exploré et couvert au niveau de l'architecture pour des raisons de sécurité. Les classes dans MQL5 vivent selon leurs propres règles en mettant l'accent sur la sécurité. Les autres types n'ont pas de poignées. Au lieu des handles pour les types et structures simples, vous pouvez utiliser des index dans les tableaux.
Les poignées elles-mêmes dans MQL5 sont correctes (croissance à partir d'une seule), vous pouvez vérifier.
1. vous voulez construire un système complexe avec des données abstraites (ce qui signifie déjà beaucoup de métadonnées et de relations internes), puis le confier à un environnement OpenCL non contrôlé où il peut être modifié de manière astucieuse. c'est pourquoi nous ne permettons qu'aux objets simples et aux tableaux de fonctionner librement sans pouvoir écraser les tables virtuelles.
2. vous demandez en fait indirectement un accès direct via la "liberté des constructions abstraites". Ce sujet a fait l'objet de recherches approfondies de notre part et est couvert par l'architecture pour des raisons de sécurité. Les classes dans MQL5 vivent selon leurs propres règles en mettant l'accent sur la sécurité.
Les poignées dans MQL5 sont correctes (à partir d'une seule), vous pouvez le vérifier vous-même.
Je veux passer des données strictement propres dans le tampon sans aucune métadonnée (handles). Je n'ai pas besoin de ces métadonnées dans le tampon. Elles me gênent. Et je ne pourrai pas non plus les y mettre - CLBufferWrite() ne les laissera pas entrer. Et c'est correct.
2. je ne demande pas vraiment d'accès direct, je peux utiliser une DLL pour l'accès direct (si j'en ai besoin).
aPointer = memcpy(a,a);
résoudra le problème de l'obtention d'un pointeur brut. Renat, essayez d'entrer dans le vrai problème. N'inventez pas quelque chose qui n'existe pas " réellement". Tout ce qui existe réellement - je l'ai décrit directement et sans aucune subtilité dans la demande. De la manière la plus constructive possible et en comprenant parfaitement les questions de sécurité.
3. C'est génial.
--
Vous ne devriez pas du tout faire de création et de suppression dynamiques de structures (new, delete). Pas même de quelque manière que ce soit. Alors les problèmes de sécurité ne se poseront pas non plus. Je comprends quel est le problème "réellement" (pour le dire dans votre langage). Il y a un problème de définition d'un type réel pour les objets dynamiques. Pour les classes, il est très probablement résolu en analysant un pointeur vers VMT. Cependant : pas de structures dynamiques, pas de problème.
Réfléchissez-y, qu'est-ce qu'une "poignée" par rapport à une entité de quelque envergure que ce soit ?
Vous pouvez fournir des poignées à des objets dont le nombre est raisonnable (classes, fichiers, etc.). Mais si vous entrez dans une zone de tableau de n'importe quelle taille, tout handle a seulement une chance d'être une référence directe à un morceau de mémoire. Sinon, la table de correspondance "poignée -> mémoire" consommera encore plus de mémoire que l'entité référencée.
Et sur la base de la disposition de sécurité, vous ne pouvez pas avoir de poignées qui sont des pointeurs directs vers la mémoire. C'est pourquoi il n'y a pas de poignée pour "toute entité non limitée".
Renat:
1. vous pouvez fournir des poignées aux objets qui sont en nombre raisonnable (classes, fichiers, etc.). Mais si vous entrez dans une zone de tableau de n'importe quelle taille, tout handle a seulement une chance d'être une référence directe à un morceau de mémoire. Sinon, la table de correspondance handle -> mémoire consommera encore plus de mémoire que l'entité référencée.
2) Et d'après la clause de sécurité, vous ne pouvez pas avoir de poignées qui sont des pointeurs directs vers la mémoire. C'est pourquoi il n'y a pas de poignée pour "toute entité non limitée".
1. Construire est une bonne chose. J'ai réfléchi. Le problème a été soulevé exactement en rapport avec les structures massives. Pour les petites structures, le temps de copie est de toute façon court. Je pense que les problèmes peuvent survenir ici uniquement en raison de la déraison de l'utilisateur, mais vous pouvez "bêtement" remplir la mémoire de toute façon (avec des tampons indicateurs, par exemple). Je ne pense pas que quelqu'un préfère travailler avec des poignées sur des structures statiques sans besoin particulier. Et si vous débordez de la mémoire, c'est votre propre faute. Ne vous préoccupez pas tant des absurdités folkloriques, il est impossible de tout prévenir (et même de tout prévoir) de toute façon. :)
Non, non. Il n'est pas nécessaire d'avoir des pointeurs directs, mais cela ne ferait pas de mal d'avoir des handles, même "pour toute entité non restreinte". L'essentiel est qu'il n'y ait aucune obligation de les utiliser. Il y aura alors assez de mémoire pour tout le monde. :)
Je ne comprends pas ce que vous aboyez ici. Si vous voulez des poignées, déclarez vos structures comme des classes, c'est tout.
Si vous voulez un accès direct à la mémoire, écrivez une dll.
Je ne comprends pas pourquoi vous vous rompez le cou ici.
1. Vous voulez des poignées, déclarez vos structures comme des classes, c'est tout.
2. si vous voulez avoir un accès direct à la mémoire, écrivez une dll.
1. C'est justement le problème : c'est problématique. Je n'ai pas besoin d'écrire un tableau de classes dans le tampon (et c'est impossible). Je dois y écrire des structures. Et je veux que ce soit rapide (sans réécrire les classes en structures). Et les poignées sont nécessaires pour un accès réordonné (pour le tri, en outre, avec des clés différentes).
Un remplacement pourrait être ma propre table d'index - mais alors je ne peux pas faire une classe encapsulant le travail avec un tableau de structures avec la possibilité d'en hériter, ainsi que des services autrefois prescrits (tri et recherche binaire).
2. Je n'en veux pas ! ! ! ! !! Arrêtez de faire un cas pour moi sur place ! :))
Non, nous ne ferons pas de telles remises. C'est un mal absolu, dont nous serons tenus responsables jusqu'à la fin.
La solution idéale serait des classes paramétrables
class MyClass<T> { T MyArray[]; .... };Mais je ne parle même plus de ça, peut-être que je devrais ?