Include questions
Blitz3D Forums/Blitz3D Beginners Area/Include questions
| ||
| My project has got a bit bulky, so I have chopped up the source. One bit for GUI, another for Math, another for Log-In stuff and so on - it's now about 7 stand alone bits of source. The main one 'Include's them all at the start of the source. What I need to ask is; Will the code in, say, block 7 of code be able to call a function in block 2? and vice versa. I suppose what I'm asking is; Does Include simply 'stitch' all your code together into one larger program, or does it simply run sequentially through the code includeing additions as they are encountered.....? |
| ||
| Whatever you include is inserted into the program you are compiling, before compilation. It's that simple. Just make sure things are declared before you call them somewhere. |
| ||
| Just to clarify. It is like Include is just like a Gosub. Therefore, Include2 won't know any of the functionality/variables of Include3,4,5 etc. It appears I'll have to knit my main code together again into one large piece so I can use all the Funcs I've written. Thanks jfk, noobs need to ask the most elementary stuff sometimes, and i really appreciate all the help and advice I get from all of you. |
| ||
| It has nothing to do with Gosub. Include 3 and 4 do "know" whatever is declared in include 1, but you cannot for example access an array in Include 1 that was dimed in include 4. Functions may be whereever you wish, their position in the code doesn't matter when you call them. You really have to imagine you are replacing the line "include "myfile.bbinc"" by the ascii content of entire myfile.bbinc. That's what the compiler does. edit: To definitely understand these things you should know more about the way the compiler works. I don't know these things in detail: There are several compiling passes, so functions and as far as I know also Types are read in a seperate pass, so there won't be a "function not found" error. This would be legal: print "hello" function do_nothin() a=0 end function print "world" end But the function would not be executed. Personally I am using a more strict structure than what Blitz3D expects: First I declare all Variables and Types, everything is initialised, then there is a mainloop, after the mainloop the end and after the End will follow all functions and DATA, if present. Last edited 2010 |
| ||
| Included files are all compiled before anything's executed, So all functions, globals and constants are declared in the Include files first before anything "runs". The "Include" does not affect runtime, only compilation. However, if there's actual procedural instructions or funciton calls in included files, these are run in order of the inclusion. I recommend just having constants, globals and variables in Include files, and all necessary dependancies included at the beginning of the 'main' file, with any procedural "runnable" code kept in the Main. Any functions, globals and constants declared in the include files can then be accessed from the Main file. Hopefully this should demonstrate it all a little clearer: If you make 3 small files with the filenames as commented below, you can then execute the 'Main.bb' and see the results! ;Main.bb Include "Inc1.bb" Include "Inc2.bb" Print "This will come FOURTH : RUNTIME MAIN" ;Inc1.bb Print "This will come FIRST : RUNTIME INC 1" Const A_String$="This will come SECOND : RUNTIME INC 1" SecondInclude() ;Inc2.bb Print "This Will come THIRD : RUNTIME INC 2" Function SecondInclude() Print A_String End Function |
| ||
| Basically, include files are just a way of managing the text files that contain your source code. They have no bearing on how the code gets compiled, or how the compiled code behaves at run-time. Source code that's broken up into include files will be compiled to exactly the same object code as source code that's all placed into the one file. One issue to be aware of though, is that relative filepaths for include files are relative to the main source file for your program, rather than being relative to the file that contains the 'Include' statement. This means that, if you have a library of systems that you use frequently in different projects, and which you incorporate into your various projects by including them, then you need to have all the code for each system inside a single file. |
| ||
| What bill said. Basically the include statement is a placeholder and the compiler will inject the included code at that marker. I tend to use a lot of types and because b3d has no Classes/methods, i tend to still use that style by using an include for every type and writing "methods" (or the functions that mostly effect/control that type) in that include. It keeps everything neat and tidy (especially when you use a proper ide like visual blitz or blide rather than the packaged one, which is -really- bad for multi-file projects!) Last edited 2010 |
| ||
| Bad in what way? I use it for multi file projects without any problems. I like the simplicity of the original ide too. To stick to the topic though, I think of includes as minimized code, like a dropdown menu that's closed. Thinking of it that way makes it easier to get it right. It's like the code's there, but in one line. Last edited 2010 |
| ||
| It's not actively bad, it just lacks useful, productivity-enhancing features, that anyone used to a grown-up IDE will miss sorely: - doesn't syntax-highlight variable or function names - doesn't highlight undeclared names as errors (OK, technically not full errors in B3D, but it's amazingly useful to have this to catch typos) - no autocomplete (this is a biggie) - indent control is poor (it only follows your manually-set indent level, not automatically moving it back and forth depending on code context and can't correct bad indenting in other people's files) - no scope completion (i.e. places an "EndIf" or "End Type" after the cursor on the next line, automatically adjusts indenting of both) - no "goto declaration", bookmarks, or fast navigation (except the rather poor menu on the right) - no code folding (i.e. "hide" blocks of code or functions you;re not currently working on) - only one "run" button (you have to switch between Release and Debug in a menu, which is a bit RSI-inducing) - no text manipulation tools except block indenting (so no bulk commenting, moving lines around with the keyboard, automatic breakpoint insertion, toUpper/toLower, etc etc.) - no concept of projects (so "run" always runs the current top file, even if it's an include, and there's no way to control imported names) - no hotcodes - have to restart the IDE to change loaded userlibs - no active-decls editor - no integration with external tools - no multiple editing windows onscreen at once - NO UNDO FEATURE AT ALL: this one will come back to bite you one day! ...those are just a few features of IDEal (it has many, many more) that I for one have come to rely on, and which make my coding experience much faster and tidier with much less effort. |
| ||
| But what about Mark's feelings? I like simple interfaces, so I'm going to keep standing on the rock that is the original ide no matter what. Unless Blitz3D programs stop working with new versions of Windows, then a column of fire will likely rise up from me. Last edited 2010 |
| ||
| The original IDE is great for quick work, but you'd might-as-well look at some of the other ones available. After switching to IDEal, I've never looked back! The original Blitz IDE is very useful as a lightweight IDE, and that's what it's intended for, but Yasha has pointed out just some of the things that are available in other heavier IDEs. But hey! Go ahead and use the original if you REALLY want to :P |
| ||
| But what about Mark's feelings? I like simple interfaces, so I'm going to keep standing on the rock that is the original ide no matter what. As far as I know the next Blitz language ("monkey", if you've been following in General Discussion) won't have an IDE at all, because Mark has no interest in them and is happy for everyone to use Blide. So you're pretty safe on that front. |
| ||
| Bad in what way? Well pretty much what yasha said:- doesn't syntax-highlight variable or function names (although i seem to remember it does :/) - doesn't highlight undeclared names as errors (OK, technically not full errors in B3D, but it's amazingly useful to have this to catch typos) - no autocomplete (this is a biggie) - indent control is poor (it only follows your manually-set indent level, not automatically moving it back and forth depending on code context and can't correct bad indenting in other people's files) - no scope completion (i.e. places an "EndIf" or "End Type" after the cursor on the next line, automatically adjusts indenting of both) - no "goto declaration", bookmarks, or fast navigation (except the rather poor menu on the right) - no code folding (i.e. "hide" blocks of code or functions you;re not currently working on) - only one "run" button (you have to switch between Release and Debug in a menu, which is a bit RSI-inducing) - no text manipulation tools except block indenting (so no bulk commenting, moving lines around with the keyboard, automatic breakpoint insertion, toUpper/toLower, etc etc.) - no concept of projects (so "run" always runs the current top file, even if it's an include, and there's no way to control imported names) - no hotcodes - have to restart the IDE to change loaded userlibs - no active-decls editor - no integration with external tools - no multiple editing windows onscreen at once But me i would settle for strict syntax, keyword intellisense, code folding, undo and project management. Basically if you use one of the alternative IDEs you will never go back. VisualBlitz is my favorite but i hear Blide is probably the best. But what about Mark's feelings? What has that got to do with anything? He wrote a great engine and the packaged IDE is nice and simple for beginners. However the IDE is unsuitable for larger more professional projects. (I am not saying impossible but it is the dev-tool equivalent of using a garden spade to do large scale agriculture)Last edited 2010 |
| ||
| What has that got to do with anything? It was a joke. I thought it would look funny after a page of criticism. Also, I can't actually cause a column of fire to rise up from me, that was a joke too. As far as I know the next Blitz language ("monkey", if you've been following in General Discussion) won't have an IDE at all, because Mark has no interest in them and is happy for everyone to use Blide. But monkeys are hideous looking creatures. He should call the new language Hot anime girl. See? Jokes. Last edited 2011 |
| ||
| It was a joke. I thought it would look funny after a page of criticism. Also, I can't actually cause a column of fire to rise up from me, that was a joke too. thats a relief ;DWhat i tend to do when doing b3d stuff my main program file looks something like this: Const version$="v1.29" AppTitle "MyApp" Include "v1.29\globals.bb" Include "v1.29\initializers.bb" Include "v1.29\Loaders.bb" Include "v1.29\Control.bb" Include "v1.29\main.bb" Each one of these will contain more includes of "Pseudo classes" aka types and control functions, which becomes a bit impossible to work with without project management. It is not ideal, but it certainly separates it out, and is about as 'modular' as it can be for a non-OOP language.. Last edited 2010 |
| ||
| I'm with D4NM4N with that last post. Huge long bits of code are a nightmare to work with, and so easy to drop an odd typo into. I like Includes, as 'yer man sez', a little lump of modular code to stick into a bigger agenda makes larger projects more manageable. Each of my .bb's has a 'header' of comments such as ;***TESTED - IT WORKS FINE dd/mm/yyyy ****, then I know not to interfere with them again (mostly). Thanks for all the info everyone. |
   |