[noob] Import
BlitzMax Forums/BlitzMax Beginners Area/[noob] Import
| ||
| An I right in thinging that Import just presents the interface(ish) of the imported file, like includeing a H file. That is it doesnt actualy put the sorce into the file, just lets your file know what function footprints exist? |
| ||
| I think it's neither. It doesn't put the source into the file, that's include, but I don't believe it just define function footprints. I think it links the object code instead. So it's like include without having to recompile. That's how I use them anyway. Code which changes constantly is included and once I have a section which won't need to be recompiled so often, I pass it off to be imported, thus reducing compile times when nothing in that code has changed. |
| ||
| Your both right. Import lets the source file know about variables, functions, types in the imported file and also lets the compiler know to link the object files together. Gabriel I would suggest just using Import if you can as the compiler will figure out if a source file needs to be recompiled or not and will save you a bunch of time. |
| ||
| there are cases where you can not come around include. Cyclic references for example enforce "include packages". But Gab is right what import does: It links the obj file of the sources and presents the exported functionality to each other. *this is everything not within a private area* |
| ||
| Gabriel I would suggest just using Import if you can as the compiler will figure out if a source file needs to be recompiled or not and will save you a bunch of time. It would actually cost me a lot of time as I'd have to be reorganizing code in order to do it. That's not worth doing until I know it's relatively permanent. |
| ||
| there are cases where you can not come around include. That's not entirely true. I've never used Include in anything I've written in Max, and I never intend to, since there is absolutely no need. If you have a problem with circular dependencies, the chances are your program logic need looking at. If you have a look at the .i files that are generated in the .bmx folder, you can get an idea of what the "interface" for a particular .bmx looks like. I imagine Include is only part of BlitzMax to provide some kind of legacy compatibility with people used to using Blitz3D/Plus. |
| ||
| Brucey: Sure thare are ways to not need include, but good OO design = 1 class per BMX file => include needed to create a BMX that merges all those classes where cyclic class dependencies exist. Its handled like this in Java and C# as well, so surely not bad design, there are just cases where it is not possible to do clean OO without cyclic class references. (with cyclic ref I mean classes that refer to classes through fields each other. Not object *class instances* that have references to each other. That is actually crap as it has a high potential for GC memory leak) And I think you agree that clean OO is much better than "I got it without cyclic class usage, just check out my pro user hack" :-) PS: Yes I normally try to get some tree like hierarchy in. But there were some cases where it was not possible without making the classes that stupid hard / complicated to use and highly unintuitive that it was just not acceptable as a solution. |
| ||
| include needed to create a BMX that merges all those classes where cyclic class dependencies exist Well I've done that, ;) Glad its good practice. But the reason I was asking the question was because I am importing things that import other things that I am also importing. (If you see what I mean) And as far as I can see this cyclic problem doesnt exist. This was in part why I asked the question in the first place, but rather than make it a big "cyclic" issue I simplifed it. (I admit that I havent gotton any cyclic Imports, but from how Ive been using Import I could have if I wanted to:- Mind you I dont like Cyclic programming so I probably wont have any) |
| ||
| I pretty much only use includes, I found import confusing. I would think that if I check the `quick compile` option the compiler would convert my includes to imports for me, and then otherwise do full includes to recompile it all. I don't see why I have to manage each file myself - not very automated. |
| ||
| Include is only a precompiler directive that copies the original source there and checks if the base rules are still valid (strict, superstrict, include, import only at top of the resulting file). H&K: That is no cyclic import at least it does not sound from your descripting What you do is multi import of the same BMX. That shouldn't be a problem, I think the compiler makes sure it is only included once. (different way: lazyness = Blide + Framework Assistant ^^ then you can be sure that only the really needed stuff is linked against that. But I would not use FA until your program is going to be shared, just to prevent stupid missing import errors) |
| ||
| I pretty much only use includes, I found import confusing So do I ;) Hence this is the third NOOB Import thread I have started. However, if you are putting one type per file (which seems a good Idea), then when you are testing/writting an extended type you want to "Include" the base type, (and I at least want superstrict). The problem with this is that in the main file you cannot now include the extended type because 1) Dupplicate includes. 2) At least 2 Superstricts.Honestly although its a pain, cos its not in my opinion as intuitive as Include, import works really well. And I dont now have to edit out all the superstricts and includes in my newly converted to import files. lazyness = Blide + Framework Assistant I love FA, the problem is tho that FA will not tell me which of my files/mods I need to Import. And more importantly in this situation I know that I am Importing the same file twice, but its staying like that because its easyer to edit individual files if I leave the multiple imports in, (Which if you see above I couldnt do with Includes). I just wanted to be sure that I wasnt giving mysefl an unnessesary overhead. not use FA until your program is going to be shared I hear you. |
| ||
| Hmm on your own files you know it. something that has been imported by one of your files does not need to be imported by a file which imports this file. So if B imports C and A needs B and C, A only needs to import B as B is already B + C when it reaches A. (import tree is solved from bottom where no import is upwards to the "main app" which normally imports everything, if this helps you understanding what it does) Beside the unneeded attempt to link it, I don't think there is a problem if A and B import C when A imports B, but don't nail me on that :) |
| ||
| something that has been imported by one of your files does not need to be imported by a file which imports this file. I know that ;)Imagine that instead of having to flip back to the main project to do a test Build, I instead just make a test Build on the specific file Im working on. Now for this to work, the specific file Im working on need to Import the right files. However when I then do want to do a complete build of the project, I normaly cannot be bothered removeing the imports on the indivigual files. This situation was impossible with Include, but with Import it is possible to do it. Beside the unneeded attempt to link it, I don't think there is a problem if A and B import C when A imports B, but don't nail me on that :) Well Im going to blame you if it goes wrong ;) |
| ||
| Problem with testbuild is, that you need to disable quickbuild afterwards, because the "head bmx" is compiled differently. You can not link against that object file later for a bmx that is importing this bmx. For that reason I try to not compile the wrong bmx as "head" or should I say: blide normally takes care of it, only work with MaxIDE / MaxIDE CE on single or 2 file projects. |
   |