Unused Arguments Aren't a Problem When Recursing Right?
nullterminatedstrings.com
Unused Arguments Aren't a Problem When Recursing Right?
1–10 of 14 posts
Re: Unused Arguments Aren't a Problem When Recursing Right?
#2Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#3ok my brain is running on empty right now but I don't really see any explanation about what the problem actually is... I get that something related to some scripting language you're using for your game isn't working, but you never actually explained what is broken.
Are unused arguments a problem when recursing? I can imagine they are if they're taking up stack space and you're doing an awful lot of recursing (I don't really use recursion enough in my C++ code to really run into issues like this, so I am a little ignorant on the side effects of recursing deeply).
Anyway it's time for bed and I'm sure this article is going to be giving me nightmares tonight.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#4gcc also doesn't detect the unused variable. Looking at the -Wunused warning description it does so correctly since a variable is considered unused if it is declared only. In this case it is also used as a parameter.
To detect it, split the recursive function into two, one that recurses and one that does the job at the end. Both can take the same relevant arguments and the latter function will detect any unused parameters.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#5Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
Even worse, foo(a,b) could call bar(a,b,c) which calls foo(b,a), all without otherwise looking at a or b. This could get really bad really fast.
But that feels like the wrong way to analyze this. Even though a full solution isn't practical, a limited one may be.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#6Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
Even worse, foo(a,b) could call bar(a,b,c) which calls foo(b,a), all without otherwise looking at a or b. This could get really bad really fast. But that feels like the wrong way to analyze this. Even though a full solution isn't practical, a limited one may be.
There is no way of fully detecting it, because of function pointers.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#7ok my brain is running on empty right now but I don't really see any explanation about what the problem actually is... I get that something related to some scripting language you're using for your game isn't working, but you never actually explained what is broken. Are unused arguments a problem when recursing? I can imagine they are if they're taking up stack space and you're doing an awful lot of recursing (I don't…
I think the problem the author is trying to bring up is that if the only place the variable is used is in a recursive call, this should be the same warning as if its not used at all. There's no way it can impact the return value (or side effects) of the function.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#8ok my brain is running on empty right now but I don't really see any explanation about what the problem actually is... I get that something related to some scripting language you're using for your game isn't working, but you never actually explained what is broken. Are unused arguments a problem when recursing? I can imagine they are if they're taking up stack space and you're doing an awful lot of recursing (I don't…
I found this a bit confusing as well at first, but it's really simple enough: The point of the article isn't the scripting language itself. It's that the author encountered a bug in the scripting language implementation that would have been found much earlier if the compiler had warned about the argument that is de facto unused.
This is a general point: More warnings can help find more bugs earlier - but you do have to worry about false positives, and warnings that increase compile time can also be a net negative.
The author's example is probably simple and efficient enough to add to a compiler, assuming that it performs some basic recursion analysis already.
Re: Unused Arguments Aren't a Problem When Recursing Right?
#9Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
Sorry, how is this O(m*n)?
Re: Unused Arguments Aren't a Problem When Recursing Right?
#10Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
This really is looking like a job for a static code analyzer. I'm all for the compiler emitting warnings as much as it can, but I also want it to compile my code very fast...
I think the right approach here is to run slow code analysis tools frequently, but less frequently than compiles.