PureBasic Forums - English

Tenaja wrote:Michael V, apparently you [...] missed my previous post

Tenaja wrote:I understand some people will not appreciate the improvement realized within the request.

Procedure test()
	
	Static a
	test:
	
	Debug @a
	a+1;
	Debug a
	a+1;
	Debug a
	a+1;
	Debug a
	
EndProcedure

test()
Debug "---"
CallFunctionFast(?test)
Debug "---"

freak wrote:The performance hit of such initializations is minimal, especially on modern processors. If speed is that critical you are probably better off doing the critical parts in asm directly. In the general case, it is simply not worth it.

rsts wrote:4 millionths of a second per variable initialization.

I'd say drop whatever you're doing and jump right on this one.

You should stick with GUI stuff in PB and utilize C for optimizing regions of code and make multi-panguage programs. It is what I do. Critical level code is written in C as libs and I use importc.

wilbert wrote:For such an option, the ideal situation would be if the PB debugger would give a warning message if a variable is used that hasn't been initialized yet.

Define NotCleared i

KJ67 wrote:To switch all on-/off in the preferences seems like playing Russian roulette with much of the code.

Tenaja wrote:This feature is no different--nor any more (or less) likely to lead to errors--than using the DEFAULT setting of DisableExplicit. Anyone who argues this feature should not be implemented may as well also argue that DisableExplicit be removed with EnableExplicit be turned on by default. So your statement is only true with old code, and with coders using habits accepted in the industry as "bad programming practices". Most compilers will not guarantee a value; PB has a safe mode, which is nice for beginners. However, most programmers who are active on this board are not beginners, and therefore have the skills to benefit from this feature request.

Tenaja wrote:Most compilers will not guarantee a value; PB has a safe mode, which is nice for beginners. However, most programmers who are active on this board are not beginners, and therefore have the skills to benefit from this feature request.

Ramihyn_ wrote:Excessive recursive solutions can be dangerous anyway, because the program/thread stack frame doesnt always dynamically grow. I just tried 250.000 recursive calls for a PB function with 2 parameters and a 32-bit executable still crashes with a stack overflow in Win7.

Tenaja wrote:I almost laughed out loud at this!!! On my current project, it is currently at 7900 lines containing over 260 procedures, and a lot more than 1/3 of them are recursive... I guess you just have to avoid the recursive summation of numbers over 1,000,000. But if you code with care, there is no problem at all with using recursion.

Ramihyn_ wrote:

Tenaja wrote:I almost laughed out loud at this!!! On my current project, it is currently at 7900 lines containing over 260 procedures, and a lot more than 1/3 of them are recursive... I guess you just have to avoid the recursive summation of numbers over 1,000,000. But if you code with care, there is no problem at all with using recursion.

For windows you can also use the Visual Studio tool "editbin" with the option "/stack:size" to extend the default stacksize in executable files. The default limit was below 65000 recursive calls for my test with 2 parameters (16 bytes on the stack for each call, 1 MB default stacksize).