HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

function with more than 31 arguments

08-17-2009, 03:32 PM#1
TheWye
Does anyone knows whether it is true that a function which has more than 31 arguments will cause a fatal error of bad memory reference? I made a constructor method for a struct which has 35 arguments and it always crashes the game when it is loading. Then I tried removing the amount of arguments one by one and it stops crashing after I removed 4 arguments. Has anyone else experienced the same thing before?

EDIT: yup.. I just confirmed this... A function cannot have more than 31 arguments or else it will cause fatal error due to bad memory reference.... and now I'm in deep sh*t. Anyone knows what to do to fix this?? or probably go around this??
08-17-2009, 03:48 PM#2
Troll-Brain
Why the hell you would need such many arguments anyway ?
Post the code.
08-17-2009, 04:02 PM#3
TheWye
Its a custom attack struct. Im making an action map so i need to define my own attacks. This struct contains information like the damage, speed, attacktype, damagetype weapontype etc. and everything else you can find in an attack.

Nevermind about the code. I think I have found a solution. I can just squeeze certain information into one argument instead of having several arguments.

Thanks for answering anyway.
08-17-2009, 04:02 PM#4
Hans_Maulwurf
you could either save some of the arguments in tempglobals or put them all in a struct and pass it.
08-17-2009, 04:27 PM#5
TheWye
hmmm.. yeah that should work. Thanks :)
08-17-2009, 06:07 PM#6
Eleandor
Easy solution: make multiple methods that need to be called after calling the constructor.
I can imagine having 31 arguments in a call is going to look very chaotic, so this may be useful anyway.

You can add a safety boolean called "init". The constructor sets "init" to false, and the 2nd method sets it to true. As long as init is false, you can't use the attack.
08-17-2009, 06:26 PM#7
Earth-Fury
Quote:
Originally Posted by Eleandor
Easy solution: make multiple methods that need to be called after calling the constructor.
I can imagine having 31 arguments in a call is going to look very chaotic, so this may be useful anyway.

You can add a safety boolean called "init". The constructor sets "init" to false, and the 2nd method sets it to true. As long as init is false, you can't use the attack.

That's horrible design. Objects should, in every possible case, always be in a valid state. This is impossible to achieve for all things, at least with any sanity, but it is a fundamental pattern that should be followed in almost all cases. Intentionally breaking from that pattern when not required to is just stupid.
08-17-2009, 06:28 PM#8
Anitarf
Anything more than 10 arguments is completely unusable anyway and anything more than 5 is pretty awkward. In situations like this, you should just let most of the struct members get initialized to default values and then change them after the struct is created with either additional methods or direct set statements.
08-17-2009, 10:30 PM#9
Eleandor
Quote:
Originally Posted by Earth-Fury
That's horrible design. Objects should, in every possible case, always be in a valid state. This is impossible to achieve for all things, at least with any sanity, but it is a fundamental pattern that should be followed in almost all cases. Intentionally breaking from that pattern when not required to is just stupid.

Having more than 31 arguments in 1 function is *good* design? I'm suggesting to break from that pattern *because* it is required.
08-17-2009, 10:36 PM#10
Earth-Fury
Quote:
Originally Posted by Eleandor
Having more than 31 arguments in 1 function is *good* design?

No.

Quote:
Originally Posted by Eleandor
I'm suggesting to break from that pattern *because* it is required.

What you suggested is replacing bad design with bad design.
08-18-2009, 06:13 AM#11
TheWye
Even warcraft units are objects with 50++ attributes. Its just that they have a nice GUI to set their values in the object editor.

Quote:
In situations like this, you should just let most of the struct members get initialized to default values and then change them after the struct is created with either additional methods or direct set statements

that means I would have 30++ lines to initiate each instance of the object. It will be even more difficult to see the code this way.

Anyway, I have found the solution of this problem. It does look horrible at first but I'm kinda used to it anyway. And I'm the only one working on this map so no one's complaining.
08-18-2009, 10:46 AM#12
DioD
use profile load.

compile profile with all values and call single function for this profile, ajust some values have fun.

you dont need to pass 50 params for projectile when you can create function "Load super projectile data"
08-18-2009, 11:09 AM#13
Anitarf
Quote:
Originally Posted by TheWye
that means I would have 30++ lines to initiate each instance of the object. It will be even more difficult to see the code this way.
Umm... Then why does the object editor have a line for each field? Doesn't that, by your logic, make unit data more difficult to see? Wouldn't it be better if all unit data was in one line of text?

No. That is as retarded as functions with 31 arguments.
08-18-2009, 12:05 PM#14
Eleandor
Quote:
Originally Posted by Earth-Fury
No.What you suggested is replacing bad design with bad design.

I don't know *what* he's trying to do, so what I'm suggesting is to spread it out over multiple methods. I don't see how that's bad design.

Having a boolean "init" was only a suggestion just in case there are no possible default values for certain fields, thus requiring certain methods to be called first. I never said this is good design, but since I have not seen his code I cannot know if there are better solutions. I'm giving the best solution given the facts I have. Ofcourse it's not a good solution, but still the best "generic" solution given that we know nothing about his code or about what he's trying to do.
08-18-2009, 02:22 PM#15
TheWye
Quote:
Umm... Then why does the object editor have a line for each field? Doesn't that, by your logic, make unit data more difficult to see? Wouldn't it be better if all unit data was in one line of text?

Let me just show you how I do things and why I want everything in just 1 line :
Hidden information:


Its easier to compare between data this way as I can see many fields in one screen. It does not look scary to me since I am the one who wrote this code. If I do it in many rows I won't be able to compare things as easily. And can you please not call what people do "retarded"? It could be quite offensive sometimes.

Anyway guys, I appreciate for all the answers and solutions you offer but I'm doing fine this way and I'm going to stick with it. And anyway, I did what Anitarf suggested by adding another method to add the values after I initiated the struct, so thank you for the suggestion, Anitarf :)