Never declare a type in a function!

BlitzMax Forums/BlitzMax Programming/Never declare a type in a function!

JoshK

(Posted 2009) [#1]

Never declare a type in a function. It will compile and run, but it will cause random memory errors down the line. I spent about four hours finding the source of a mem leak, and this was it.

For that matter, you should stay away from functions in functions as well.

slenkar

(Posted 2009) [#2]

Brucey

(Posted 2009) [#3]

Never declare a type in a function.

Why would you want to?

Htbaa

(Posted 2009) [#4]

Why would it even be possible? I think it's strange the compiler doesn't complain about it. But even so, I agree, why would you want to? Anonymous/private types or something?

markcw

(Posted 2009) [#5]

What if you make it global? Can you declare it global in the function?

Perturbatio

(Posted 2009) [#6]

What if you make it global? Can you declare it global in the function?

A global inside a function becomes a static variable, not a global in the traditional sense.

JoshK

(Posted 2009) [#7]

Why would you want to?

I had a type for a DDS header structure that was only used in my DDS load function.

markcw

(Posted 2009) [#8]

Oh that's right, I wasn't sure if it applied to types.

What if you Null all local types before the function ends? Does it still leak?

JoshK

(Posted 2009) [#9]

It's not a regular leak, though. It can run perfectly fine without causing a leak. When combined with other commands, sometimes it can leak. Sometimes it won't. I experienced something similar with functions in functions with a global variable in the main function, like this:

Function foo()
	Global thing:Int=3
	do()
	
	Function do()
		Print thing
	EndFunction
	
EndFunction

It appears to work fine, but will cause random memory overwrites. At least, in older versions of BMX it did.

I've occasionally been getting a bad refs error, and I think my type in a function was the cause. These are the worst things to debug, because their behavior changes when you change the code. But I am reasonably certain this was the cause, since I can now load and free complex objects in a loop with no leaks. I've got a pretty uniform approach to code, for the most part, and this was one place where I deviated from my norm.

Wiebo

(Posted 2009) [#10]

Interesting. Lately, I've been using functions in methods.. Anyone ever had problems with that? I have not so far.

Brucey

(Posted 2009) [#11]

I've been using functions in methods..

You mean, like this?

Method blah()

    Function doodah()

        Print "Yippee!"

    End Function

    doodah()

End Method

I wouldn't advise it.

grable

(Posted 2009) [#12]

I have had no trouble with Functions within Functions or Methods..
There should be no difference in the generated code, as they are all static.
(just dont go messing with fields, globals are ok though)

ImaginaryHuman

(Posted 2009) [#13]

I think there was some piece of BRL code which actually declared functions within functions, so presumably that works okay?

plash

(Posted 2009) [#14]

I think there was some piece of BRL code which actually declared functions within functions, so presumably that works okay?

Yeah, I think functions inside of functions/methods works fine.

Although, I was under the impression that the encapsulated function was just renamed to "encapsulator_name" + "_" + "encapsulated_name" (or something of the such) when it compiled.
If you look at the assembly code... that isn't at all how it works. Bummer.

Wiebo

(Posted 2009) [#15]

I wouldn't advise it.

Why not Brucey? I value your opinion but I also need facts =]

But it would be nice to an official answer to this.. It's very intriguing.