SuperStrict Declaration
BlitzMax Forums/BlitzMax Programming/SuperStrict Declaration
| ||
I'm not sure if this is a bug or a 'feature' lol... Is it possible to make Blitz ignore SuperStrict declarations in an include file? It's a little annoying to have to comment out SuperStrict in an include file before executing the main file |
| ||
You think that is bad? The opposite is worse. If you use SuperStrict and include a file that didn't, you have to go through that include file and fix all of the declaration that aren't typed. Talk about annoying. :) Everybody should use SuperStrict. It should be the default. ;) |
| ||
It's a little annoying to have to comment out SuperStrict in an include file before executing the main file Ah. Use Import instead :-) "but I can't, because A needs B and B needs A" Ah. Improve your design. :-p |
| ||
Thanks.. I didn't realize you could use import *like* include... that solves it. "but I can't, because A needs B and B needs A" Was that a pre-answer to an expected response? or coming from that other thread that discussed the issues I was having trying to glue verletMax into tilemax? Either way... I have ;) I tore it out LOL |
| ||
http://www.blitzbasic.com/Community/posts.php?topic=59760#667130 |
| ||
Was that a pre-answer to an expected response? Well, it's a typical response to why someone can't use Import. (I wasn't implying this might be your response, but getting it in there before it came up again ;-) The other advantage to using Import, is that, since each .bmx is compiled as a separate binary, build times can be much reduced, because only those files which have been changed and those importing that changed file require to be re-compiled. When you Inlcude, everything is recompiled - and depending on how much code you have in there, that can take a reasonable amount of time. The way I work, a quick, code/compile/test cycle, I don't have time to sit around waiting for everything to build. But the choice is there. Each to their own, etc :-) |
| ||
One thing about Imports. If you are distributing a mod, anyone using the mod will need the imports. They do not get compiled into your mod. |
| ||
If you are distributing a mod, anyone using the mod will need the imports. They do not get compiled into your mod. What don't ? Imported modules? |
| ||
Yes, imported modules. I am not not sure about bmx files themselves. Will have to try it to be sure. |
| ||
One thing about Imports. If you are distributing a mod, anyone using the mod will need the imports. They do not get compiled into your mod. If you're distributing a module in compiled form, you'll see how evey import has its corresponding interface and object files. distribute them aswell and it'll work too. importing is done at link time, not at compile time. That's why you can mix C with C++ and BlitzMax easilly (well easilly depending on what you're doing, and depending on if you're Brucey :D ) EDIT: Ok, you were talking about modules being imported by other modules. Then yes, you'll have to distribute the compiled binaries of them or their source code. |
| ||
Ok, you were talking about modules being imported by other modules Right. Everything else is compiled into the .a archive file. If you want, you can ship a module with only the .i and .a files present in the module folder - that is enough to build an app against. anyone using the mod will need the imports This is reasonably obvious, I'd have thought. And you'll get a message at compile time if you try to build your app and one of those imported mods are missing. I usually list any requirements with my modules - like, my datetime module also requiring the boost module. (I even have distributions which combine sets of modules together, so the user doesn't have to download several different things). But... this is all drifting off topic rather :-) |