Questions from a "dummy" - page 127

[Vladimir Gomonov]

Renat:

Dear Sir, watch the context.

1) When you jump from one controlled and safe environment to a completely uncontrolled raw buffer, you are the one responsible for compatibility with that binary environment.

2) When you write code, you are responsible for the architecture of that code. And don't whine that "it's hard to put a horse and a doe in the same cart" when you use different structures.

3) I recommend that you read the description of CLBufferRead and CLBufferWrite - thanks to the universal void* reference, you can pass any type of reference to OpenCL. And there are offsets and sizes as well.

1. I am ready for this responsibility. // adjusting an imaginary tie and struggling to hold back laughter.

2. I'm not crying. It's just silly to write your own two or three-dimensional arrays that seem to already exist in the language. And you have to.

3. I will check it. In the old version, passing of a two-dimensional array did NOT work. Didn't try it in the new one from old memory.

// ArrrayCopy() also seems to have your void, but it is plush and applies only to array type, not dimension.

Went to check the third item.

[Renat Fatkhullin]

You are exactly crying and accusing us of shortcomings in the process. So no need to clown around.

About multidimensional arrays:

• Multidimensional arrays work.
• use OOP, keep/hide arrays inside classes
• less unreasonable passing of multidimensional arrays as parameters.
  
• actively use structures - they make life and control much easier, reducing complexity.
  

Immediately it will get easier and more correct.

[Vladimir Gomonov]

Renat:

You are exactly crying and accusing us of shortcomings in the process. So no need to clown around.

About multidimensional arrays:

• Multidimensional arrays work.
• use OOP, keep/hide arrays inside classes
• Less unreasonable passing of multidimensional arrays as parameters
  
• actively use structures - they make life and control much easier, reducing complexity.
  

It will immediately become easier and more correct.

And my discontent was well grounded because (for instance) this code did not work in the previous version:

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

And I had to rewrite the array redundantly two times in each processing loop (see the commented code).

In another version I made a virtual own object array (like Nikolai's), but it's clumsy to use (especially when writing the genetics) - functional syntax is exhausting in places.

Now the code works, the two-dimensional array is actually written to the buffer. This is progress. :)

OK, Peace, Friendship, Gum... :) If you do operator overloading, I'll fix the syntax myself.

[Renat Fatkhullin]

Operator overloading already done, will be available in the next build.

[Vladimir Gomonov]

Renat:
Operator overloading already done, will be available in next build.

Wow !!! That's a nice touch.

Many thanks to the whole development team for that !

Now it will be possible to write really nice code.

[Mykola Demko]

Renat:
Operator overloading has already been done, will be available in the next build.

Why so small letters? It's a rhetorical question.

Better like this:

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

[Anatoli Kazharski]

Operator overload is a new concept for me. I found a detailed description here: http://programmersclub.ru/24/

Is this it?

[Mykola Demko]

tol64:

Operator overload is a new concept for me. I found a detailed description here: http://programmersclub.ru/24/

Is this it?

Yes it is.

[Vladimir Gomonov]

Urain:

Why so small letters? It's a rhetorical question. I prefer that:

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

Yes, it's going to be a very solemn build.

:)

[Vladimir Gomonov]

Renat:

I'm afraid you didn't want to notice the overlap in description:

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

The second option is much cleaner, more powerful and with more control. There is no resonance in inventing another weaker entity in the existing way.

The second version of the description is not the problem. The problem is that when you use it, the syntax doesn't change for the better.

I offer you a powerful and absolutely safe compromise : "default" fields. The keyword default completely solves the syntax differences. :)

In this case.

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

(C++ does, C# does, Delphi does, etc.)

I.e. when accessing such a field, just write Int8Var[i] instead of Int8Var.arr[i] - the compiler will understand correctly.

// And the main thing is not to forget to do this not only for classes, but for structures as well. :)