Domande da un "manichino" - pagina 127

[Vladimir Gomonov]

Renat:

Caro signore, guardi il contesto.

1) Quando si salta da un ambiente controllato e sicuro a un buffer grezzo completamente incontrollato, si è responsabili della compatibilità con quell'ambiente binario.

2) Quando si scrive codice, si è responsabili dell'architettura di quel codice. E non lamentatevi che "è difficile mettere un cavallo e una cerva nello stesso carro" quando usate strutture diverse.

3) Vi consiglio di leggere la descrizione di CLBufferRead e CLBufferWrite - grazie al riferimento universale void*, potete passare qualsiasi tipo di riferimento a OpenCL. E ci sono anche compensazioni e dimensioni.

1. Sono pronto per questa responsabilità. // aggiustando una cravatta immaginaria e lottando per trattenere le risate.

2. Non sto piangendo. È semplicemente stupido scrivere i propri array bidimensionali o tridimensionali che sembrano già esistere nel linguaggio. E devi farlo.

3. Lo controllerò. Nella vecchia versione, il passaggio di un array bidimensionale NON funzionava. Non l'ho provato in quello nuovo di vecchia memoria.

// ArrrayCopy() sembra anche avere il vostro void, ma è plush e si applica solo al tipo di array, non alla dimensione.

Sono andato a controllare il terzo elemento.

[Renat Fatkhullin]

Lei sta esattamente piangendo e ci sta accusando di mancanze nel processo. Quindi non c'è bisogno di fare il pagliaccio.

Informazioni sugli array multidimensionali:

• Gli array multidimensionali funzionano.
• usare OOP, tenere/nascondere gli array all'interno delle classi
• meno irragionevole il passaggio di array multidimensionali come parametri.
  
• utilizzare attivamente le strutture - rendono la vita e il controllo molto più facili, riducendo la complessità.
  

Immediatamente diventerà più facile e più corretto.

[Vladimir Gomonov]

Renat:

Tu piangi e ci accusi di mancanze. Quindi non c'è bisogno di fare il pagliaccio.

Riguardo agli array multidimensionali:

• Gli array multidimensionali funzionano.
• usare OOP, tenere/nascondere gli array all'interno delle classi
• Passaggio meno irragionevole di array multidimensionali come parametri
  
• utilizzare attivamente le strutture - rendono la vita e il controllo molto più facili, riducendo la complessità.
  

Diventerà immediatamente più facile e più corretto.

E il mio malcontento era ben fondato perché (per esempio) questo codice non funzionava nella versione precedente:

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];}}
  }

E ho dovuto riscrivere l'array due volte in più in ogni ciclo di elaborazione (vedi il codice commentato).

In un'altra versione ho fatto un array virtuale di oggetti propri (come quello di Nikolai), ma è anche goffo da usare (specialmente quando si scrive la genetica) - la sintassi funzionale è estenuante in alcuni punti.

Ora il codice funziona, l'array bidimensionale viene effettivamente scritto nel buffer. Questo è il progresso. :)

OK, Pace, Amicizia, Gomma... :) Se fai l'overloading dell'operatore, sistemerò la sintassi io stesso.

[Renat Fatkhullin]

Sovraccarico dell'operatore già fatto, sarà disponibile nella prossima build.

[Vladimir Gomonov]

Renat:
Il sovraccarico dell'operatore è già stato fatto, sarà disponibile nella prossima build.

Wow!!! Questo è un bel tocco.

Molte grazie a tutto il team di sviluppo per questo!

Ora sarà possibile scrivere del codice veramente bello.

[Mykola Demko]

Renat:
Il sovraccarico degli operatori è già stato fatto, sarà disponibile nella prossima build.

Perché lettere così piccole? È una domanda retorica.

Meglio così:

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

[Anatoli Kazharski]

Il sovraccarico degli operatori è un concetto nuovo per me. Ho trovato una descrizione dettagliata qui: http://programmersclub.ru/24/

È questo?

[Mykola Demko]

tol64:

Il sovraccarico degli operatori è un concetto nuovo per me. Ho trovato una descrizione dettagliata qui: http://programmersclub.ru/24/

È questo?

Sì, lo è.

[Vladimir Gomonov]

Urain:

Perché lettere così piccole? È una domanda retorica. Lo preferisco:

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

Sì, sarà una costruzione molto solenne.

:)

[Vladimir Gomonov]

Renat:

Temo che non abbia voluto notare la sovrapposizione della descrizione:

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

La seconda opzione è molto più pulita, più potente e con più controllo. Non c'è risonanza nell'inventare un'altra entità più debole nel modo esistente.

La seconda versione della descrizione non è il problema. Il problema è che quando lo usi, la sintassi non cambia in meglio.

Vi offro un compromesso potente e assolutamente sicuro: i campi "default". La parola chiave default risolve completamente le differenze di sintassi. :)

In questo caso.

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

(C++ lo fa, C# lo fa, Delphi lo fa, ecc.)

Cioè quando si accede a un tale campo, basta scrivere Int8Var[i] invece di Int8Var.arr[i] - il compilatore capirà correttamente.

// E la cosa principale è non dimenticare di farlo non solo per le classi, ma anche per le strutture. :)