Questions from a "dummy" - page 125

[Renat Fatkhullin]

MetaDriver:

Oh, now I see.

Renat, I have a suggestion for a long time, and it is exactly on the subject. Please make a named typing for arrays, at least for static ones (all other types already have it).

I.e. possibility to declare for example: typedef Int8 = int[8];.

It can be easily done through structures. We will not over complicate it.

struct Int8 { int arr[8]; };

[Vladimir Gomonov]

Renat:

This is easily done through structures. Let's not overcomplicate it.

Great. Easy. That's what we do! But what do I need? A simple thing??

Do not you think that your razor Occam and our (user) Occam's razor are two very different razors. You with your minimalism, tend to create such a surplus in users, that it is time to hang Occam on the nearest fence.

If you care so much about simplicity, then make it possible to pass usual subarrays into functions! Everybody will be happy, and minimalists are happy.

// By the way, it works fine in F4 - also for dynamic ones. :)

[Yedelkin]

Renat:
Static, of course.

Well, there you go. Too late to check :/

[Renat Fatkhullin]

MetaDriver:

Oh, great. That's easy. That's what we do! But what do I need? On the level ??

The structures I'm proposing are a standard way of creating new entities.

There's no need to get excited over nothing.

[Renat Fatkhullin]

MetaDriver:

Currently, in mql5, we have to make a lot of extra steps and write a lot of crooked code due to impossibility to pass subarrays into functions.

You are talking about pointers to uncontrollable memory chunks, which is completely forbidden in MQL5.

In MQL5 every object/type must be controllable - this is a direct requirement for language security.

If you need to pass part of an array, you should use passing of reference to the array itself and its position. This will give you full control over the array itself.

[Vladimir Gomonov]

Renat:

You are talking about pointers to uncontrollable memory chunks, which is completely forbidden in MQL5.

In MQL5 every object/type must be controllable - this is a direct requirement for language security.

2. If you want to pass part of an array, use passing a reference to the array itself and the position in the array. This will work for full control of the array itself.

Moreover, it's the only place where naming is not implemented, so it fits well into the ideology of universalization of language entities.

2. All the same: firstly, it is crooked, and secondly, it is not universal at all. Suggest a way(1) to copy a two-dimensional mql-array into an OpenCL buffer without unnecessary rewriting and wrapping into structures, or(2) using (for speed) your own function ArrayCopy(...) for non-uniform arrays.

// Sorry for the abruptness of the previous post. Really unnecessary. I got excited at "let's not complicate things". As it just leads to complications.

2a. I think your "one-dimensionality constraint" for functions like ArrayCopy() can be softened painlessly in many cases with one elementary clause in the comments: "The function works with multidimensional arrays too, as long as the multidimensional array is copied in its entirety. "

A lot of problems would disappear. // But not all, of course.

[Renat Fatkhullin]

MetaDriver:

1. That was my suggestion to introduce naming and hence rigid typing, especially since this is the only place not covered by naming, hence fits well with the ideology of universalization of language entities.

I'm afraid you didn't want to notice the coincidence of the description:

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

The second way is much cleaner, more powerful and controllable. There is no reason at all to invent another weaker one using the existing method.

2. doing the same thing. All the same: firstly, it's crooked, and secondly, it's not universal at all. Suggest a way(1) to copy a two-dimensional mql-array into an OpenCL buffer without unnecessary rewriting and wrapping into structures, or(2) to use (for speed) your own function ArrayCopy(...) for non-dimensional arrays.

Firstly, it is not crooked. Secondly, security is higher than any optimization methods in the style of direct uncontrolled memory access. That is, the question "how can I directly pour a binary block into a controlled entity" is a general and fundamental (poorly solvable) one for all languages.

If you have to deal with array transfers between different systems (in OpenCL), it is important to think about a simple and directly compatible data structure.

Look at the simplest CLBufferWrite multi-typed function bound class for easy data transfer.

[Vladimir Gomonov]

Renat:

You're talking about pointers to uncontrolled pieces of memory, which is completely forbidden in MQL5.

And by the way, you are condensing. The compiler knows the size of the array being passed at the point where the parameter is passed.

It even generates an error when trying to do so. :) Another thing is that you would have to introduce additional implicit parameterization at every function call (roughly as you advise me to do explicitly). But the solution on your side would be much more universal - for example, by using your own standard library of functions and objects. The same ArrayCopy() and FileWriteArray() would work without problems.

[Renat Fatkhullin]

papaklass:
You can accompany your statements with simple examples, for people like me. MetaDriver understands you, but people like me don't understand what we are talking about without any examples? And you want to be aware of what's going on.

I'm afraid this will be a substitute for documentation. Look it up in a search - there's just a ton of information out there.

Safe access to some array members:

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

Taking into account that the compiler is very sharpened for inline functions, in fact, the function may be completely built into the call place and all the overhead will be reduced to zero.

It means, in MQL5, you can not be afraid of writing small "correct" functions - they have a standard full inline fate with the appropriate optimization.

This means that the costs of parameter transfer and indexing are reduced.

[Renat Fatkhullin]

MetaDriver:

And by the way, you are condensing. The compiler knows the size of the array being passed at the point of parameter passing.

Since when did all the arrays become static, as well as all the indices and sizes?

Since arrays are almost always dynamic and indexes are variables, we cannot make any serious static checks at the moment of a call. You only have to do meta/rtti checks and that's why it's so important to have access to the whole object/description and not work on a piece of memory at random.

The same ArrayCopy() and FileWriteArray() would work without any problems.

Don't worry, everything has been thought out a long time ago.

The consequences of breaking the security principles we know very well is the "in April we fixed 12 more critical bugs to break out of the virtual machine and gain control of the system" way.