Questions d'un "mannequin - page 125

[Renat Fatkhullin]

MetaDriver:

Oh, maintenant je vois.

Renat, j'ai une suggestion depuis longtemps, et elle est exactement sur le sujet. S'il vous plaît faire un typage nommé pour les tableaux, au moins pour les statiques (tous les autres types ont déjà).

C'est-à-dire la possibilité de déclarer par exemple : typedef Int8 = int[8] ;.

Cela peut se faire facilement par le biais de structures. Nous ne le compliquerons pas du tout.

struct Int8 { int arr[8]; };

[Vladimir Gomonov]

Renat:

Cela se fait facilement grâce aux structures. Ne compliquons pas trop les choses.

Super. Facile. C'est ce que nous faisons ! Mais de quoi ai-je besoin ? Une chose simple ?

Ne pensez-vous pas que votre rasoir Occam et notre rasoir (d'utilisateur) Occam sont deux rasoirs très différents. Vous avec votre minimalisme, tendez à créer un tel surplus d'utilisateurs, qu'Occam devrait se pendre à la clôture la plus proche.

Si vous tenez tant à la simplicité, faites en sorte qu'il soit possible de passer des sous-réseaux habituels dans les fonctions ! Tout le monde sera content, et les minimalistes sont contents.

// D'ailleurs, cela fonctionne bien en F4 - également pour les dynamiques. :)

[Yedelkin]

Renat:
Statique, bien sûr.

Eh bien, voilà. Trop tard pour vérifier :/

[Renat Fatkhullin]

MetaDriver:

Oh, super. C'est facile. C'est ce que nous faisons ! Mais de quoi ai-je besoin ? Au niveau ? ??

Les structures que j'ai proposées sont un moyen standard de créer de nouvelles entités.

Il n'y a pas besoin de s'exciter pour rien.

[Renat Fatkhullin]

MetaDriver:

Actuellement, dans mql5, nous devons faire beaucoup d'étapes supplémentaires et écrire beaucoup de code tordu en raison de l'impossibilité de passer des sous-réseaux dans les fonctions.

Vous parlez de pointeurs vers des morceaux de mémoire incontrôlables, ce qui est totalement interdit dans MQL5.

Dans MQL5, chaque objet/type doit être contrôlable - c'est une exigence directe pour la sécurité du langage.

Si vous devez passer une partie d'un tableau, vous devez utiliser le passage de la référence au tableau lui-même et à sa position. Cela vous donnera un contrôle total sur le tableau lui-même.

[Vladimir Gomonov]

Renat:

Vous parlez de pointeurs vers des morceaux de mémoire incontrôlables, ce qui est totalement interdit dans MQL5.

Dans MQL5, chaque objet/type doit être contrôlable - c'est une exigence directe pour la sécurité du langage.

2. si vous voulez passer une partie d'un tableau, utilisez le passage d'une référence au tableau lui-même et la position dans le tableau. Cela fonctionnera pour un contrôle total du tableau lui-même.

De plus, c'est le seul endroit où le nommage n'est pas mis en œuvre, il s'inscrit donc bien dans l'idéologie de l'universalisation des entités linguistiques.

2. Tout de même : premièrement, il est tordu, et deuxièmement, il n'est pas du tout universel. Suggérez un moyen(1) de copier un tableau mql bidimensionnel dans un tampon OpenCL sans réécriture et enveloppement inutile dans des structures, ou(2) en utilisant (pour une utilisation rapide) votre propre fonction ArrayCopy(...) pour les tableaux non uniformes.

// Désolé pour le caractère abrupt du message précédent. Vraiment inutile. Je me suis excité à "ne compliquons pas les choses". car cela ne fait qu'entraîner des complications.

2a. je pense que votre "contrainte d'unidimensionnalité" pour des fonctions comme ArrayCopy() peut être adoucie sans douleur dans de nombreux cas avec une clause élémentaire dans les commentaires : " La fonction fonctionne également avec les tableaux multidimensionnels, à condition que le tableau multidimensionnel soit copié dans son intégralité. "

Beaucoup de problèmes disparaîtraient. // Mais pas tous, bien sûr.

[Renat Fatkhullin]

MetaDriver:

1) C'était ma suggestion d'introduire le nommage et donc le typage rigide, d'autant plus que c'est le seul endroit qui n'est pas couvert par le nommage, ce qui correspond bien à l'idéologie de l'universalisation des entités linguistiques.

J'ai peur que vous n'ayez pas voulu remarquer la coïncidence de la description :

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

La deuxième méthode est beaucoup plus propre, plus puissante et plus facile à contrôler. Il n'y a aucune raison d'en inventer une autre plus faible en utilisant la méthode existante.

2. faire la même chose. Tout de même : premièrement, c'est tordu, et deuxièmement, ce n'est pas du tout universel. Suggérez un moyen(1) de copier un tableau mql bidimensionnel dans un tampon OpenCL sans réécriture inutile ni enveloppement dans des structures, ou(2) d'utiliser (pour la vitesse) votre propre fonction ArrayCopy(...) pour les tableaux non dimensionnels.

Tout d'abord, il n'est pas de travers. Deuxièmement, la sécurité est supérieure à toutes les méthodes d'optimisation dans le style de l'accès direct non contrôlé à la mémoire. Autrement dit, la question "comment puis-je verser directement un bloc binaire dans une entité supervisée" est une question générale et fondamentale (mal résolue) pour tous les langages.

Si vous devez gérer des transferts de tableaux entre différents systèmes (dans OpenCL), il est important de penser à une structure de données simple et directement compatible.

Examinez la classe liée à la fonction multi-types CLBufferWrite la plus simple pour faciliter le transfert de données.

[Vladimir Gomonov]

Renat:

Vous parlez de pointeurs vers des morceaux de mémoire non contrôlés, ce qui est totalement interdit dans MQL5.

Et au fait, vous condensez. Le compilateur connaît la taille du tableau passé au moment où le paramètre est passé.

Il génère même une erreur lorsqu'il essaie de le faire. :) Une autre chose est que vous devriez introduire un paramétrage implicite supplémentaire à chaque appel de fonction (à peu près comme vous me conseillez de le faire explicitement). Mais la solution de votre côté serait beaucoup plus universelle - par exemple, en utilisant votre propre bibliothèque standard de fonctions et d'objets. Les mêmes ArrayCopy() et FileWriteArray() fonctionneraient sans problème.

[Renat Fatkhullin]

papaklass:
Vous pouvez accompagner vos déclarations d'exemples simples, pour les personnes comme moi. MetaDriver vous comprend, mais les gens comme moi ne comprennent pas ce dont nous parlons sans aucun exemple ? Et vous voulez être conscient de ce qui se passe.

Je crains que cela ne remplace la documentation. Faites une recherche - il y a une tonne d'informations.

Accès sécurisé à certains membres du tableau :

void MyFunc(double& array[],uint pos,uint size)
  {
   while(size>0)
     {
      Print("[",pos,"] = ",array[pos]);
      pos++;
      size--;
     }
  }

Si l'on tient compte du fait que le compilateur est très affûté pour les fonctions inline, en fait, la fonction peut être complètement intégrée dans le lieu d'appel et toute la surcharge sera réduite à zéro.

Cela signifie que, dans MQL5, vous ne pouvez pas avoir peur d'écrire de petites fonctions "correctes" - elles ont un sort standard full inline avec l'optimisation appropriée.

Cela signifie que les coûts de transfert des paramètres et d'indexation sont réduits.

[Renat Fatkhullin]

MetaDriver:

Et au fait, vous condensez. Le compilateur connaît la taille du tableau passé au moment du passage des paramètres.

Depuis quand tous les tableaux sont-ils devenus statiques, ainsi que tous les indices et les tailles ?

Comme les tableaux sont presque toujours dynamiques et que les index sont des variables, nous ne pouvons pas effectuer de contrôles statiques sérieux au moment d'un appel. Il suffit de faire des contrôles méta/rtti et c'est pourquoi il est si important d'avoir accès à l'ensemble de l'objet/description et de ne pas travailler sur un morceau de mémoire au hasard.

Les mêmes ArrayCopy() et FileWriteArray() fonctionneraient sans problème.

Ne vous inquiétez pas, tout a été pensé depuis longtemps.

Les conséquences de la violation des principes de sécurité que nous connaissons très bien sont les suivantes : "En avril, nous avons corrigé 12 autres bogues critiques pour sortir de la machine virtuelle et prendre le contrôle du système".