Including source code ? (Solved)
Monkey Forums/Monkey Beginners/Including source code ? (Solved)
| ||
| Hi, Is it possible with Monkey to include source code ? I dont' mean build a function library but really include a piece of source code like the preprocessor command {$I} in Pascal syntax or #include in C/C++. Thank you Golomp |
| ||
| You mean like what C++ does when you use "cpp" files, instead of headers? For one thing, in C++ that's not usually the best approach, but that's another topic. That's what it sounds like, and that has been purged from Monkey for the sake of modularity and consistency. Importing ('Import') works better, and there aren't any major differences. BlitzMax and Blitz Basic have Include, though. BlitzMax's 'Import' works differently than Monkey's, however. Just stick to using proper imports, they're what the language was built around. |
| ||
| Thank you ImmutableOctet. And between Ted and Trans batch process, is it possible to include a preprocessing file? thank you Golomp |
| ||
| If I'm understanding the Pascal nomenclature, you want a file that sets up preprocessor functionality ala C++'s header setup, right? Because that's not really a thing in Monkey either (Not in the same way, that is). But it's not like I didn't try to convince Mark otherwise. Monkey's preprocessor unfortunately can't be used value-wise. In other words, you can't go define a variable with the preprocessor, and use its value in-line with your code (Like what's done with C++). That can be done with the external languages, though. For example, C++ based targets have the "CFG_" prefix in front of Monkey's preprocessor variables (This may change at some point; use at your own risk). Everything else can basically be done without a preprocessor in Monkey. Constants are basically preprocessed, anyway; that's why you can have constants in functions. That's also why it can be both good and bad to use constants for strings. On one hand, you have a unified storage for the string (Global), but people can modify it if it's public to them. On the other hand, you have strings generated every time you use that constant. In the case of constants, they're usually better, as it makes the memory footprint smaller, and they're handled differently on some targets (Mostly memory-wise; they're functionality is effectively the same). As for just managing the preprocessor, then you can have a separate module for that. Monkey has its own "CONFIG.monkey" file it generates, which is basically just a normal module. You can do the same thing with any other module, in fact, I've done that before. The preprocessor can be used in any file, though. And as of V82(A), the change I proposed to the preprocessor has been implemented. This means imports are counted into the preprocessing step, so you can preprocess before, and after your imports. If that's not what you're talking about, then I'm lost. The only other thing I can think of is writing your own preprocessor, or modifying 'trans' yourself. |
| ||
| Hi ImmutableOctet, Thank you for your explanations, i know better Monkey internal now. Excuse me if my question was not very clear and/or if i confuse you, i am french and sometime it's not very easy to explain myself. (well, even in french i have the same problem ;) My question was just about including a pure piece of code (for example an array of integer for a matrix. This array is generated by an other program and is large) I think i am going to use the import possibilities to manage it and i am going to generate the source code of a little library in text format (i mean the array plus the source code around to obtain a correct monkey source file). After that the import will do the job. Thank you again ImmutableOctet. Regards Golomp |
| ||
| If the array is very large, then using an external (Non-source) file might be ideal. You'd have to load it with one of the loading methods, though. In the case of games, the file would normally be located in the application's "BUILD_FILE_NAME_HERE.data" folder (A similar setup as the "*.build" folder). This isn't required for some targets; for example, the C++ Tool (STDCPP) target can deal with any file-locations, as there's normally not a data-folder. Most (If not all) other desktop targets can read data from other locations. Android also has support for other storage locations. From there, you could read the file using either 'FileStream.Open' (This will open a stream you'll need to read from; generally preferable, but not always needed), 'LoadString' (This loads the entire file into a string; the size is limited on some targets), or 'DataBuffer.Load' (If you need all of the data at once, and you don't need to deal with it until later, this is your best bet). If it's very large, and you want your code to be elegant / not huge, then you should do this. Smaller amounts of data can be stored in arrays via Monkey without any problems. Also note that the 'LoadString' option is not available for the C++ Tool (STDCPP) target without using the semi-deprecated 'os' module (Desktop C++ targets only). Data commonly stored in the executable's storage sector is usually small, and tends to be done for the sake of reducing runtime cost. If you're simply dealing with data from an external source, loading from a file is recommended. If you go the 'DataBuffer' route, you'll be able to either peek (Read) the data from it, or you can use the 'DataStream' class. I'd recommend using a 'DataBuffer' (Via 'DataBuffer.Load'), and simply using the 'PeekInts' method, once the data has been loaded. This will provide a standard integer array for you to use. Also note that 'Import' can also be used for non-source files (Not always the best setup), this will save them to the "*.data" folder when compiling. If the data you're dealing with is actually generated by code you can use in Monkey, then it's really up to you about how you should handle this. |
| ||
| Hi Golomp, if you try to load Monkey source code at runtime, then I am pretty sure that the answer is no. Even using import won't help you here. All code must be translated and compiled when you build the app. |
   |