One-dimensional or two-dimensional. The tasks have different answers because you won't make the same code for both. Or rather you may do it, but you won't be able to call it without knowing beforehand the number of measurements in the array. Since you are not a programmer, judging by your words, I suggest that you take it on faith
If we look at the problem this way, then multidimensional arrays should not be declared at all - arrays of structures with different fields should be used instead. But the question is different - what can we do with an array of arbitrary (unknown in advance) dimensionality that already exists as a given
You are deadlocked then :( . Why don't you like the variant with several functions?
Aliaksandr Hryshyn: What's not to like about the multiple function option?
By having to duplicate the same code (the same one you're talking about), in functions with different names for each different dimensionality of the parameter array
Dmitry Fedoseev: Arrays don't have more than 4 dimensions here. So, you can write 4 different functions and that's it.
The problem is not in writing 4 functions, but in not being able to use one for any array, as is the case with any other types. That's why it's better to avoid using multidimensional arrays (built-in type []) in µl at all
by the way, typename, available at compile time, will not tell not only about number of measurements, but even about the fact that the parameter is an array. although it can be understood by sizeof==52. but again, it will not tell anything about number of measurements. so I do not see any convenient solution via #define either. Unless all of the function code, using only embedded calls like ArrayCopy and ArrayResize, to which different array dimensions can be passed, could be shoved into define
Although I don't remember exactly, but it seems that the second and next measurements cannot be dynamic. Correspondingly, there may be errors when compiling such code. Here, the size_second_dimension variable can be used as a set size of the second dimension and allow to overload the function. Plus, it avoids the need to define the dimensionality through ArrayRange()
Although I do not remember exactly, it seems the second and the next measurements cannot be dynamic. Correspondingly, there may be errors in compilation of such code. Here size_second_dimension variable can be used as the predefined size of the second dimension and allows to overload the function. Plus, it avoids the need to define the dimensionality through ArrayRange()
It will compile, but it's not interesting, and what about z[][][]?
The second and above measurements cannot be dynamic, but the function doesn't have to be customised for a particular size of the second dimension, it can be found out through ArrayRange().
If the number of measurements won't allow to overload the function, the size of the second and other measurements certainly won't. Besides, it's not interesting at all, since it is not universal at all. It would be easier to write functions with different names.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
Task: remove an element from an array.
Task: remove an element from an array.
One-dimensional or two-dimensional. The tasks have different answers because you won't make the same code for both. Or rather you may do it, but you won't be able to call it without knowing beforehand the number of measurements in the array. Since you are not a programmer, judging by your words, I suggest that you take it on faith
Arrays cannot have more than 4 dimensions here. So, you can write 4 different functions and that's it.
Can't you build an 8-dimensional one?
If we look at the problem this way, then multidimensional arrays should not be declared at all - arrays of structures with different fields should be used instead. But the question is different - what can we do with an array of arbitrary (unknown in advance) dimensionality that already exists as a given
What's not to like about the multiple function option?
By having to duplicate the same code (the same one you're talking about), in functions with different names for each different dimensionality of the parameter array
Arrays don't have more than 4 dimensions here. So, you can write 4 different functions and that's it.
The problem is not in writing 4 functions, but in not being able to use one for any array, as is the case with any other types. That's why it's better to avoid using multidimensional arrays (built-in type []) in µl at all
Can't you make an 8-dimensional one?
The structures are easy to use.
Eh, and overloading doesn't save it:
Will it compile like this?
Although I don't remember exactly, but it seems that the second and next measurements cannot be dynamic. Correspondingly, there may be errors when compiling such code. Here, the size_second_dimension variable can be used as a set size of the second dimension and allow to overload the function. Plus, it avoids the need to define the dimensionality through ArrayRange()Will it compile like this?
Although I do not remember exactly, it seems the second and the next measurements cannot be dynamic. Correspondingly, there may be errors in compilation of such code. Here size_second_dimension variable can be used as the predefined size of the second dimension and allows to overload the function. Plus, it avoids the need to define the dimensionality through ArrayRange()It will compile, but it's not interesting, and what about z[][][]?
The second and above measurements cannot be dynamic, but the function doesn't have to be customised for a particular size of the second dimension, it can be found out through ArrayRange().
If the number of measurements won't allow to overload the function, the size of the second and other measurements certainly won't. Besides, it's not interesting at all, since it is not universal at all. It would be easier to write functions with different names.