Max # of variables passed before using struct
-
Question: What is the maximum # of variables you like to pass into a function before you decide it needs redesigning to use a struct or some other method? I have an old math library, some functions take 10 parameters. Just curious if there was any "common-sense" standard. (I have no common-sense, so I have to ask....) - Codin' Carlos
-
Question: What is the maximum # of variables you like to pass into a function before you decide it needs redesigning to use a struct or some other method? I have an old math library, some functions take 10 parameters. Just curious if there was any "common-sense" standard. (I have no common-sense, so I have to ask....) - Codin' Carlos
The number that I have grown accustomed to is 7. But that is more because I used to program for Sun machines, and that is the number of variables that would be placed in registers before they were passed on the stack. This is not really an issue with the VC++ compiler because it always passes the paraemters on the stack. Therefore a sensible number between 4 and 7 is good, but it will not hurt you to have a number of parameters like 10. It just becomes more cumbersome.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Question: What is the maximum # of variables you like to pass into a function before you decide it needs redesigning to use a struct or some other method? I have an old math library, some functions take 10 parameters. Just curious if there was any "common-sense" standard. (I have no common-sense, so I have to ask....) - Codin' Carlos
IMHO, if this struct isn't getting passed around multiple times between the main subroutine and internal subroutines, there is little point in using structures. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
IMHO, if this struct isn't getting passed around multiple times between the main subroutine and internal subroutines, there is little point in using structures. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Right-o ol' bean. In this case, the main routine will be calling the same few routines every time the user updates a numerical edit box or two. So putting into struct would be 'faster' and more efficient; Putting as individual parameters is more 'programmer friendly' and self documenting (only need function declaration, not function and structure declaration)??? hmmmmm.... - Codin' Carlos
-
Right-o ol' bean. In this case, the main routine will be calling the same few routines every time the user updates a numerical edit box or two. So putting into struct would be 'faster' and more efficient; Putting as individual parameters is more 'programmer friendly' and self documenting (only need function declaration, not function and structure declaration)??? hmmmmm.... - Codin' Carlos
It might also be more efficient to pass the struct by reference. /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
-
Right-o ol' bean. In this case, the main routine will be calling the same few routines every time the user updates a numerical edit box or two. So putting into struct would be 'faster' and more efficient; Putting as individual parameters is more 'programmer friendly' and self documenting (only need function declaration, not function and structure declaration)??? hmmmmm.... - Codin' Carlos
putting it in a struct might be faster for the actual call, since you only have to pass the address of the struct (if you're passing by reference). but you still have to put the stuff in the struct, which will probably take just as long as putting the stuff on the stack. i only put things in structs when the parameter list itself gets too long for easy reading (somewhere around 8 or 10 items). -c
//The Mandelbrot set
o(int O){putchar(O);}main(){float l[8],O,I=.05;char _;for(l[6]=15;l[6]<':';o
(10),l[5]=-'$'*I+l[6]++*I)for(l[7]=-5;l[7]<'@';l[4]=-'('*I+l[7]++*I,o(_?'?':':'))for
(*l=O=0,_=1;++_&&((l[2]=*l**l)+(l[3]=O*O)<4);O=*l*O+l[5]+O**l,*l=l[2]-l[3]+l[4]);} -
The number that I have grown accustomed to is 7. But that is more because I used to program for Sun machines, and that is the number of variables that would be placed in registers before they were passed on the stack. This is not really an issue with the VC++ compiler because it always passes the paraemters on the stack. Therefore a sensible number between 4 and 7 is good, but it will not hurt you to have a number of parameters like 10. It just becomes more cumbersome.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!I did a little more research and found that if you only use between 1-3 input parameters, depending on what you do inside of your function, then compiler is able to use the registers as input parameters. x86 does not have that many free registers, so if you use them up on input parameters, there will be no registers to perform operations with. Hope this extra information will make a difference.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Question: What is the maximum # of variables you like to pass into a function before you decide it needs redesigning to use a struct or some other method? I have an old math library, some functions take 10 parameters. Just curious if there was any "common-sense" standard. (I have no common-sense, so I have to ask....) - Codin' Carlos
In fact, for readability a structure will be preferable particulary if there are no hint about what each parameters are: f(true, false, true, true, true); Looking at this code it's hard to know what the third parameter means (and it is easy to swap parameters by errors). As mentionned in another answer, 7 parameters are generally what is considered as a maximum for readability... Structures or classes also allows to set parameters to default values. If everything is inline and a good compiler is used, the compiler should be able to remove useless initialisation. Structures or classes (I prefer classes with private members), also allows to easily add a parameter, have default options or compute parameters. Also if most parameters are optional and different subset are used depending on the context, different constructors can be provided. Finally as someone else said, if the function is called only from a few places it will be simpler (faster) to pass all those parameters than to define a structure (or a class). But if the code is often used, a better design is in order. The best solution is to make a class with all the data private and inline accessor as this will greatly simplify maintenance if you need additional parameters (or you want to remove obsolete parameters). Philippe Mori
-
I did a little more research and found that if you only use between 1-3 input parameters, depending on what you do inside of your function, then compiler is able to use the registers as input parameters. x86 does not have that many free registers, so if you use them up on input parameters, there will be no registers to perform operations with. Hope this extra information will make a difference.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!kilowatt wrote: x86 does not have that many free registers Actually, it doesn't have that many registers at all, free or not. :-) But you seem to be right in your assessment of how MSVC handles the case, only that I've never seen it reduce it to one single fre GPR. Two, possibly, but never one. Also worth to keep in mind is that MSVC hardwires ECX to the 'this' pointer for member functions, reducing the number of free GPR's to 3 (only two more than it's Z80 relative - no wonder since they both are created at about the same time :-> ).