SUPERSTICT vs STRICT - Optimum code differences?
BlitzMax Forums/BlitzMax Programming/SUPERSTICT vs STRICT - Optimum code differences?
| ||
| Does SuperStrict create 'better' optimized code than the same code compiled under Strict? Or, is it simply a case of Superstrict ensuring that you "dot the I's and cross the T's"? The reason I ask is, the main BRL code seems to be entirely STRICT based. Would Superstricting the source make a jot of a difference in terms of memory management, optimizations, or speed? |
| ||
| As I understand it, it doesn't make any difference to how the code compiles - the options are there simply to eradicate sloppy coding. I'm not sure what the difference is between Strict and SuperStrict either. I always use Strict. |
| ||
| From what I could tell, the only difference I've encountered between Strict and SuperStrict is that in SuperStrict mode, if you define a function and you don't specify that it has a return type, but you try to use Return with a parameter, it will tell you you haven't specified a specific return type in the function declaration. Also vice versa, if you define a function that returns a specific type of data, any calls to Return within the function that include a parameter must pass back something of the same type you declared. This is okay: Function MyFunction:Float() Return End Function Function MyFunction2:Float() Return RndFloat() End Function Function MyFunction3() Return End Function but this is not okay: Function MyFunction() Return RndFloat() End Function Function MyFunction2:Float() Return Rand(0,5) End Function Both Strict and SuperStrict are there to help with writing the source code and avoiding bugs - ie Strict makes sure you declare your variables before you use them so that you don't accidentally create new ones on the fly when you have a typo. SuperStrict goes the extra step of requiring function return types to be correct. As far as I know, neither affects the final executable, but they may help compile the code faster. |
| ||
| In strict you don`t have to declare data type for integers - everything which is declared without data type is automatically integer. The same goes for function return value data type, if none is specified than it is integer. I don`t know if there are other differences but this one should not affect code optimization (according to logic, but I never heard Mark saying that). |
| ||
| I think one of them (Strict I think) does mean that the compiler can make some basic optimisations. |
| ||
| The only significant difference between them for me is compile time. some of my apps used to take up to a minute to compile but when someone on the forums finally was more hard headed than me and convinced me to try super strict out, my compile time is now 5-10 seconds for even the longest programs. Also my code is not sloppy anymore so it helps with that. |
| ||
| SuperStrict for the win. |
| ||
| Far as I know, there's no speed/build time difference between Strict/SuperStrict, but I haven't made a point of testing it. The only time I use SuperStrict instead of Strict these days is when I'm working on one of my hundreds of test-*.bmx files (~/ is getting cluttered..). |
| ||
| I don't think SuperStrict speeds anything up, but it surely makes code A LOT easier to go through. I really wish Mark wrote all the modules in SuperStrict, but alas he did not. |
| ||
Strict forces you to declare variables/functions/methods as Local or Global, but does the default-to-Int thing, eg.a = 20 ' Bad Local a = 20 ' Fine -- default to Int Local a:Float = 20.0 ' Fine -- Float SuperStrict forces you to also declare the type, eg. a = 20 ' Bad Local a = 20 ' Bad Local a:Int = 20 ' Fine The docs do seem to have disappeared, though! |
   |