Import vs Include
BlitzMax Forums/BlitzMax Beginners Area/Import vs Include
| ||
| I feel like I'm cluttering up the forums with a bunch of silly questions lately... But then, I suppose we're all new once, and I'm not gonna learn any other way. :P As I understand it, Import is relevant to things like modules, which I have also gathered are pre-built code collections which are passed to GCC for compiling along with whatever code you've created. I have learned that, for instance, Import can be used to import specific modules into a minimalized Framework program, i.e. telling BlitzMax "I don't want everything, just these particular ones." What I'm wondering is this. I know that Include is now generally touted as deprecated, and the use of Import is encouraged for all scenarios. What I'm wondering is this: if I'm just including one .bmx file in another - like I always did with Include, in Blitz3D - is there any difference between Include and Import? |
| ||
| I know that Include is now generally touted as deprecated, and the use of Import is encouraged for all scenarios. It is? I use Include extensively.Import is handy on large projects used in conjunction with QuickBuild. Basically if you have a stand-alone class and use Import rather than Include, that class will only be recompiled if changes have been made to it, speeding up the compilation process. Whereas if you use Include, all of the code is lumped together into one massive block of code, then compiled. In the latter case, QuickBuild is of little use. |
| ||
| Files that are "linked" with include, generate a single "obj" file at compile time. That is, they're a single unit and they can't usualy be compiled one without the other. Files linked with "import" are sort of stand-alone. You can import a file that includes other files. what you'll be doing will be import the "obj" that is generated when this file is compiled. They're sort "compilation clusters". In fact, modules in BlitzMax are built this way. |
| ||
| Huh. So really then, for the size of the projects I'm likely to be working on, I can just stick to using Import as necessary for modules. Fair 'nuff. |
| ||
| So really then, for the size of the projects I'm likely to be working on, I can just stick to using Import as necessary for modules. Fair 'nuff. That's what I do (for Magicville (which code-wise, was big), CS, and my new game), and it works out fine for me.Don't be railroaded into using Import because anybody tells you "it's cool" to do so, or it's "the proper way". Use it if you want to/need to, but if not, then don't. Because at the end of the day, the end-user doesn't give a toss whether you used Import or Include, and it's the end-user's opinion that matters. |
| ||
| One minor thing to add to the above is that since the result forms a single translation unit (basically a source file after pasting), Include also renders Public/Private meaningless, because they apply the visibility restriction at the "file" level. If you weren't using them, this is irrelevant. In your own "internal" code, you probably weren't. |
| ||
| Also, using Framework and Import will allow you to build smaller exe files in case you only use a small portion of BMax code. For example, you create something that doesn't use any network code, so it's rather irrelevant to put all BMax code into your final exe. Using Framework and Import allows you to exclude the networking modules from your exe, making it smaller. This can be handy if you want your final exe to be released via the internet and your webspace is limited. |
| ||
| for me import means its compiled seperately from the main file, this also means it needs all its files to be included too. include means that its part of the main file as if the source was included into it |
   |