Hi there,
Im pretty new to maxscript (started learning it last week) and Im wondering about return statements in functions.
The maxscript reference says that return statements should be avoided because its implemented using C++ exceptions.
In the limited scope my first script would use returns, performance isnt that big a deal, but Im wondering what the alternatives to a return statement might be. I could use global variables, but I generally like to keep that to a minimum.
The reference also says Instead, simply place the result expression at the end of a function body.
Ill give that a try, but how does slapping the result at the end of the function body generate a return? Is that method something inherent in maxscriptthe last expression in the function is returned to the calling code?
Any hints?
Thanks,
Alec
The ‘return’ issue is a bit strange. According to a PM Bobo sent to me, the MXS help isn’t accurate anymore. If you put ‘return’ at the end of a function, MXS is smart enough to just ignore it. When return does come into play is when you break out of a function early.
But let’s back up a second to understand what functions pass out. If you use a return statement, the function will pass out whatever value is returned. However, if no return is supplied, a function will simply pass out the last value MXS generates. If your last line is an assignment (a = b + c), your function will return a; but you could just have (b + c) at the end of a function since you aren’t doing anything with a. For loops will return undefined, for example; an if/then will return whatever the last evaluated value is. ‘set’ functions often return a value of ok. It is a good idea for a function that doesn’t return anything (such as, say, setting the position of an object) to return OK or something similar.
Well this is all fine and good for putting things at the end of a function, but what happens if you want to break out early? Well if you truly want to break out, you’ll need to use a return statement. But what you are usually able to do, is create some sort of value that you will return at the end of the function. So for example, instead of:
fn test a b =
(
if a < b then return 0
else if a == b then return 1
else return 2
)
you should use:
fn test a b =
(
local ret
if a < b then ret = 0
else if a == b then ret = 1
else ret = 2
ret
)
Well that’s the idea. Actually the code could be optimized by getting rid of ret entirely, but the idea of ret is to illustrate there are alternatives to using a return. Very rarely, a return is unavoidable, but there is almost always a better way.
I think that’s a really good explanation of the issue. I personally like “return”, I can see where the functions ends as I’ve trained myself to look for it, and have avoid it since I read that section in the docs to.
Nice one!
Awesome post, Rob. Thanks for the detailed description.
I guess what the docs explained are true, but I just couldn’t believe it. It just sounded too weird.
Thanks again.
Alec
The return (as well as try()catch()) really causes a delay when the function in question is called hundreds of thousands or millions of times. If it is called just once from time to time, the delay would not be measurable. So if you are writing some iterative code (like nested FOR loops to loop through rows and columns of pixels in a bitmap) and you are calling some function from inside these loops, having a return statement in the middle of the function to PREMATURELY exit the function would likely cause measurable slowdowns (up to orders of magnitude). If the return is at the end of the function, it would not cause a slowdown.
These are things you should start worrying about after a year or so of scripting. It is good to keep them in mind, but in the beginning, getting your code running has higher priority than “running with style”
I was initially worried and started rewriting all my functions but then actually did some performance testing and found negligible at best differences for most usages and decided to just ignore it unless it was a function that I knew would be called at least 2 times in a second.
I have some functions which are going to take 150ms as it is so losing one ms is going to be unnoticeable and I know it won’t be called multiple times so I just ate the time difference. Of course in the functions that are taking .9ms and need to come down to .4ms that’s where it’s a really good thing to be aware of.
Knowing that it ignores the end return does explain why most of the time I found no difference in 90% of my scripts.
I must admit I started using return in my scripts when I saw it in a few others, I had always assumed I was something I was missing off. However my previous scripts had returned functions without problem.
“These are things you should start worrying about after a year or so of scripting”
I must be a basket case by now then!
What if, after six years, I still can’t get my code running?
Do what the rest of us do…keep trying