User Module mixed C++

Monkey Forums/Monkey Programming/User Module mixed C++

nigelibrown (Posted 2014) [#1]

My module has the structure: modules/module/module.monkey modules/module/native/module.cpp modules/module/module.h in my module.cpp I include the header with #include "../../module.h" but it is not looking for the header file in the module directory, it is looking for it in my project folder. Question: How can I include the module.h file in my module.cpp from the module structure? Else I have to copy the module.h file into all of my projects and it is no longer modular. I would like to store it in the native folder along with the cpp files.

MikeHart (Posted 2014) [#2]

../../ means it goes 2 levels up which is your modules folder.

nigelibrown (Posted 2014) [#3]

Mike, thats the problem its not! "../../module.h" is actually looking in the project that imports the module using "Import module.module' it will find the module.h file if you place it inside the project?

Sub_Zero (Posted 2014) [#4]

@nigelBrown: If that is the problem, you can copy files to the project folder during build time (or else they always get overwritten): http://www.monkey-x.com/Community/posts.php?topic=3377#36970

nigelibrown (Posted 2014) [#5]

Best solution I have found to date is to use an absolute path i.e "#include "c:\Monkey81b\modules\module\native\module.h" not a very modular approach i know! There must be a better way of achieving this?

skid (Posted 2014) [#6]

Can't you get trans to import (inline) the header just like it is doing with the cpp? You could then remove the #include altogether. Or just paste your header into your cpp, .h files don't really make sense in monkey modules. I found for serious native code development with monkey, using my own target was best. I would typically attach some test cases and use a native IDE to debug the native code / target before adding any monkey apps to the mix.

ImmutableOctet(SKNG) (Posted 2014) [#7]

If I remember right, Monkey doesn't play well with header files. I'd say your best bet for this effect is to just rename the headers to CPP files (Possibly "*.h.cpp"; that's what I usually go with), then you just import them first. It's a bit of a hack, but it works pretty well. I ended up doing this with symbolic links in the past. Well, either that, or you make a new target. I just use the C/C++ preprocessor for projects that are for standard C/C++ and Monkey at the same time. I simply don't import any of the project-local header files if a custom Monkey flag/variable is enabled/defined (Which I obviously define myself). I honestly think we should patch 'Trans' to just support header files, at least then we wouldn't have to add ".cpp" to everything. Or maybe we could add something for getting the module's global path from C++ (Maybe through the Monkey and C++ preprocessors)? That's a bit of a stretch, though. The thing is, Monkey isn't the best at producing the most optimal structure for its generated code (Unless it's JavaScript, then it's not bad). With the C/C++ based targets, it simply adds it all to one file. That being said, this approach is actually pretty good performance-wise. The issues really start coming in when you have 20+ large modules on top of the default modules along with the reflection filter set to everything ("*"). Then you end up having GCC/MinGW sit there for 20 minutes using 800+ MB of RAM, doing effectively nothing. But, that could technically be seen as an optimization issue with the standard 'reflection' module. Anyway, the point I'm trying to make is that external C/C++ code in Monkey is overall different. You can use anything you want, but if you delegate it to Monkey, you could run into issues. If you want a really nice experience with this, you'll probably just want to either have your users grab the C/C++ version, set it up with their compiler's includes and what-not, then use the library normally from external C or C++ code at Monkey's level. Either that, or what I said earlier (Which is more hassle for you, but less hassle for them). And don't get me started on adopting Monkey's "object model" for the sake of supporting the garbage collector without using a wrapper (It's not that bad, it's just annoying; only really needed for the classes being directly worked with, though). You basically need to pick a trade-off.