Page 1 of 1
Problem calling macro with non byte type array parameter
Posted: Sat Sep 01, 2012 1:34 am
by Mantas
Hello MM,
I had this issue before, but no one addressed it. I was trying to expand a 2d array program written by Enamul, to include all the matrix manipulations like transverse, inverse and ect. But i have come up to a problem. If you create a macro with a array type parameter which is byte type, so there is no problem calling it. But as soon as you change the array parameter type to any other like for example float, you can no longer call the macro no matter what you enter in to parameter field when you are calling the macro. It just pops a warning message "can not convert to type "float[4]" or any other type except for byte type. Why is that? here is an example program:
Try entering the transpose macro and there you will see the call read array macro, and try entering transv_array in to the field. You will sooon notice that it is not possible.
Best regards,
Mantas
Re: Problem calling macro with non byte type array parameter
Posted: Sat Sep 01, 2012 10:33 am
by Enamul
Hi,
You are right about the issue of floating array passing..But I have sorted that in different way..My version is demo version..that's why I can't complete display portion of transpose matrix..But I think you can add that bit. You can display original Matrix first in the following format:
X=[1.123 2.234]
3.345 4.456
After transposing, you can display like that..
X'=[1.123 3.345]
2.234 4.456
Re: Problem calling macro with non byte type array parameter
Posted: Sat Sep 01, 2012 8:01 pm
by Mantas
And one more thing about the array parameters in macro. In C language it is possible to create an array parameter with undefined dimentions like:
Code: Select all
void example (double 2d_array[][] )
{
code...
}
It would be very handy if it was also possible in the flowcode, in that way you could use the same macro for any size array. But flowcode does not allow creating parameter with empty [] brackets. Any comments about that?
Best regards,
Mantas
Re: Problem calling macro with non byte type array parameter
Posted: Sun Sep 02, 2012 9:20 pm
by JonnyW
Thank you. I am sorry - this bug has slipped by us I'm afraid. I will get this sorted ASAP for the next release, but I do not know when we have a release scheduled.
As far as pointers go, yes it would be useful for Flowcode to be able to do this, I can look into the impact on the exe for this. I think there may be problems with the generated C code as Flowcode assumes a length is specified for all arrays, but to limit this to parameters only could make the generation work. Can't promise anything but it would be good to have.
Jonny
Re: Problem calling macro with non byte type array parameter
Posted: Thu Sep 06, 2012 10:37 am
by Mantas
Hello Jonny,
Nice to hear that this will be fixed. Well in my opinion it's better to release the update later but with more fixes than just update with several minor fixes. Also, sometimes in C you are able to create an array with a predefined dimension as a variable or a constant:
Code: Select all
double earth_periodic_term_summation(const double terms[][TERM_COUNT], int count, double jme)
{
int i;
double sum=0;
for (i = 0; i < count; i++)
sum += terms[i][TERM_A]*cos(terms[i][TERM_B]+terms[i][TERM_C]*jme);
return sum;
so array terms[][TERM_COUNT] uses not a digit but a variable, or constant as a second dimension.
This would be also handy
Well, anyway I have my trust in you! You can do it!
Best regards,
Mantas
Re: Problem calling macro with non byte type array parameter
Posted: Fri Sep 07, 2012 11:28 pm
by JonnyW
Hi. Note this is not so much a bug fix as a feature addition - Flowcode never really supported passing arrays as arguments or assigning one array to another (except strings) in any version, and there is different code generation to be done for arrays than other types.
As far as the number of elements in parameters go, in the C code this value does not really matter - you can overflow the array anyway and it is still the same pointer as was passed in. Its Flowcode that uses that value to judge the size of the array to check for overflows, etc - it is more of an 'upper-limit' than the true array size. However this is moot if FC wont let the code pass arguments.
It is not a massive job to implement, but because playing about with code generation rules effect so much of the system in ways that can not easily be tested we have to be careful. It will also effect the CAL if we do if tor all assignments (which is how it should be) as routines need to be written to make copies of arrays.
I am leaning towards making this a later v5 release or possibly even something for a major revision because of potential implications and because I would like to do it correctly. In future revisions we would like to support robotics and other 3D-space manipulation programs more thoroughly, so this will be a necessity before long.
Jonny