Questions d'un "mannequin - page 127

[Vladimir Gomonov]

Renat:

Cher Monsieur, regardez le contexte.

1) Lorsque vous passez d'un environnement contrôlé et sûr à un tampon brut totalement incontrôlé, vous êtes le seul responsable de la compatibilité avec cet environnement binaire.

2) Lorsque vous écrivez du code, vous êtes responsable de l'architecture de ce code. Et ne vous plaignez pas qu'"il est difficile de mettre un cheval et une biche dans la même charrette" lorsque vous utilisez des structures différentes.

3) Je vous recommande de lire la description de CLBufferRead et CLBufferWrite - grâce à la référence universelle void*, vous pouvez passer tout type de référence à OpenCL. Et il y a aussi des décalages et des tailles.

1. Je suis prêt à assumer cette responsabilité. // ajustant une cravate imaginaire et luttant pour retenir le rire.

2. Je ne pleure pas. Il est tout simplement stupide d'écrire ses propres tableaux à deux ou trois dimensions qui semblent déjà exister dans le langage. Et tu dois le faire.

3. Je vais le vérifier. Dans l'ancienne version, le passage d'un tableau à deux dimensions ne fonctionnait PAS. Je ne l'ai pas essayé dans le nouveau de mémoire ancienne.

// ArrrayCopy() semble aussi avoir votre void, mais il est en peluche et ne s'applique qu'au type de tableau, pas à la dimension.

Je suis allé vérifier le troisième élément.

[Renat Fatkhullin]

Vous êtes exactement en train de pleurer et de nous accuser d'avoir des lacunes dans le processus. Donc pas besoin de faire le clown.

À propos des tableaux multidimensionnels:

• Les tableaux multidimensionnels fonctionnent.
• utiliser la POO, garder/cacher les tableaux dans les classes
• le passage moins déraisonnable de tableaux multidimensionnels comme paramètres.
  
• utiliser activement les structures - elles facilitent la vie et le contrôle, en réduisant la complexité.
  

Immédiatement, cela deviendra plus facile et plus correct.

[Vladimir Gomonov]

Renat:

Vous pleurez et nous accusez d'avoir des défauts. Donc pas besoin de faire le clown.

À propos des tableaux multidimensionnels:

• Les tableaux multidimensionnels fonctionnent.
• utiliser la POO, garder/cacher les tableaux dans les classes
• Passage moins déraisonnable de tableaux multidimensionnels comme paramètres
  
• utiliser activement les structures - elles facilitent la vie et le contrôle, en réduisant la complexité.
  

Il deviendra immédiatement plus facile et plus correct.

Et mon mécontentement était bien fondé car (par exemple) ce code ne fonctionnait pas dans la version précédente :

void gpuCalculate()
  {
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {nets[i*CountInd+j]=NETs[i][j];}}
//   CLBufferWrite(cl_Mem_NET,nets);
   CLBufferWrite(cl_Mem_NET,NETs);
   CLExecute(cl_Krn,1,Offs,Works);
   CLBufferRead(cl_Mem_Result,Result);
//   CLBufferRead(cl_Mem_NET,nets);
   CLBufferRead(cl_Mem_NET,NETs);
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {NETs[i][j]=nets[i*CountInd+j];}}
  }

Et j'ai dû réécrire le tableau deux fois de plus dans chaque boucle de traitement (voir le code commenté).

Dans une autre version, j'ai créé un tableau d'objets virtuels propres (comme celui de Nikolaï), mais il est également maladroit à utiliser (surtout lors de l'écriture de la génétique) - la syntaxe fonctionnelle est épuisante par endroits.

Maintenant le code fonctionne, le tableau à deux dimensions est réellement écrit dans le tampon. C'est un progrès. :)

OK, Paix, Amitié, Chewing-gum... :) Si vous faites de la surcharge d'opérateurs, je corrigerai moi-même la syntaxe.

[Renat Fatkhullin]

La surcharge des opérateurs est déjà faite, elle sera disponible dans la prochaine version.

[Vladimir Gomonov]

Renat:
La surcharge des opérateurs est déjà faite, elle sera disponible dans la prochaine version.

Wow ! !! C'est une belle touche.

Un grand merci à toute l'équipe de développement pour cela !

Il sera désormais possible d'écrire du code vraiment agréable.

[Mykola Demko]

Renat:
La surcharge des opérateurs a déjà été réalisée, elle sera disponible dans la prochaine version.

Pourquoi de si petites lettres ? C'est une question rhétorique.

C'est mieux comme ça :

Перегрузку операторов уже сделали, будет доступно в следующем билде.

[Anatoli Kazharski]

La surcharge des opérateurs est un nouveau concept pour moi. J'ai trouvé une description détaillée ici : http://programmersclub.ru/24/

C'est ça ?

[Mykola Demko]

tol64:

La surcharge des opérateurs est un nouveau concept pour moi. J'ai trouvé une description détaillée ici : http://programmersclub.ru/24/

C'est ça ?

Oui, c'est vrai.

[Vladimir Gomonov]

Urain:

Pourquoi des lettres si petites ? C'est une question rhétorique. Je préfère ça :

Перегрузку операторов уже сделали, будет доступно в следующем билде.

Oui, ça va être une construction très solennelle.

:)

[Vladimir Gomonov]

Renat:

Je crains que vous n'ayez pas voulu remarquer le chevauchement des descriptions :

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

La deuxième option est beaucoup plus propre, plus puissante et permet un meilleur contrôle. Il n'y a pas de résonance à inventer une autre entité plus faible de la manière existante.

La deuxième version de la description n'est pas le problème. Le problème est que lorsque vous l'utilisez, la syntaxe ne change pas pour le mieux.

Je vous propose un compromis puissant et absolument sûr: les champs "par défaut". Le mot-clé "par défaut" résout complètement les différences de syntaxe. :)

Dans ce cas.

struct   Int8 
  { 
    int arr[8]; default;
  };

(C++ le fait, C# le fait, Delphi le fait, etc.)

Par exemple, pour accéder à un tel champ, il suffit d'écrire Int8Var[i] au lieu de Int8Var.arr[i] - le compilateur comprendra correctement.

// Et l'essentiel est de ne pas oublier de le faire non seulement pour les classes, mais aussi pour les structures. :)