(only Warfley understood correctly that this was my requirement, prob I did not explain it well enough).
No, I understood that as well. But it's still idiotic to abuse parameters like that.
(There is a reason there is a limit to parameters.)
If you need to do this in your code (and have it check number of param at compile time) then there is something wrong with your design (code or otherwise). You should build in the checks at other points (for example at receiving set values).
There seems to be a fault in design-thinking but we can't seem to get that across.
You could still work with a record.
For example type MyRecord23 (with your 350 values).
When you add a new field, and you would need to change all functions using it, you can also rename the record MyRecord24 at that point. During compile time you will get all the places where you used the (now non existing old) MyRecord23, so also all the places calling of that function, and you can change the code one step at a time.
You could also search all instances of that record in your whole project.
Really... there is a reason you never ever see such code around with 350 parameters.
The solution of renaming record is ok of course, and the process would be this (correct me if I am wrong):
- add to the record the new field
- rename the record type to a new name
- compile and get the errors to see everytime record was referred
- add the assignments missing in every place record is used and rename it in order that next compile this error point vanishes, until program compiles again (
make sure you don't do mistakes because if you miss to add the new assignment your record will pass thru the function call anyway)
- rename the record to the original name
- compile and get the errors to see everytime record was referred
- fix all names to original until program compiles again
With the new parameter in the function the same was achieved like this:
- add the parameter the new function
- compile and get the errors to see everytime function is referred
- add the new parameters values until program compiles again
In the second there are less steps (and to me this seems also less error prone) so this is why I liked most.
But with the 255 limitation, I will probably use the record approach.
Another good of the record approach that it is impossible to get with the params, it that record can ba passed by pointer, and this speeds up the function call (seen that values passed wont be modified inside function in my case).
Recent
