Passing an object to an extern function
Monkey Forums/Monkey Programming/Passing an object to an extern function
| ||
| Is it possible to pass a monkey "Object"-object to the c++ world. And if yes is it possible to cast it to the type the object was before becoming on object (i.e. to an instanve of a specific class)? And if yes, how do I know in c++ code the real type of this object? |
| ||
When using native C++, you can accept any type from Monkey by using a pointer. The exact type depends on the object in question, but the argument can simply be an 'Object*' (Object pointer), just as you would with 'Object' in Monkey (Compiles to the same thing). To pass exact types, you'd be going for a target/"generator" specific approach. In such situations, you'll want to look at the generated source to see what the class's encoded name is. A different way of doing this would be to use native base-classes like what Monkey does with most of its official modules (See 'brl.databuffer' for details). If you want to use a dynamic cast (As-in what Monkey does if you cast a reference to a class into a reference to a derivative class), then you'd use: "dynamic_cast<insertTypeHere>(pointerHere)" - I'm not really going to teach you C++, if that's what you want. Just note that on most targets (Including the standard C++ implementation in 'monkey.lang'), the 'Object' class in C++ uses the same name. The only difference is, Monkey automates references/pointers, and C++ doesn't. If you want to pass an 'Object' to a function in C++ (By reference / through Monkey), then you'd need to write something like this:
void test(Object* o) { /* Insert function here/between the brackets. */ }
|
| ||
| Thank you very much. I will try it. No, I don't know that you teach me in c++ ^^. |
| ||
Now I got the following error: "c_IntObject undeclared identifier" in this line:c_IntObject* realType = dynamic_cast<c_IntObject*>(v); Because the decaration of the IntObject class takes place a few thousand lines later. And the (maybe stupid) question is: Is it possible to use "Monkey"-classes in extern c++ code? |
| ||
| No its not possible ... that is what i want and asked it so long time ago ... |
| ||
| Ok, Thank you :( |
| ||
| my mate and me tried to optimize transcc in this case... but its very hard to handle it easy... offtopic: where are you from? Ackermann sounds like from germany or similiar? |
| ||
| Yep, I'm from germany. But born in asia. That's the story about my first name :) EDIT: Habe dich hinzugefügt. |
| ||
| * |
| ||
| As k.o.g. pointed out, no it's not possible without some hacks to the compiler or target (As far as C++ code goes); stick to the external code already provided beforehand. This mainly applies to the standard 'brl' module, the 'monkey' module's external functionality, and any other module which uses external C++ code. This is an issue because the main program needs the explicit external code to work, but then your own explicit external code requires the code below it. I've been meaning to bring this up to Mark; most notably, how the preprocessor-changes could potentially change external code ordering (Not an issue for most situations, of course). But... If you wanted to use some less graceful methods (Mainly target modification, really), you could use proper external C++ files and/or headers. There's also some terrible things you could do with the compiler's code generation, where you could throw in extra code and what-not. I don't really recommend these things, though. There is a workaround for this with functions, however. Since the linker deals with functions, you can have prototypes wherever you want. This means you can access any function you please from any point in the code, as long as you declare its prototype beforehand in your external code. Not exactly the best idea, but it's something. You also cause problems with future-proofing code-bases if you do this; the Monkey code can't change the native prototype(s) (Return type, name, and arguments). At this point, just don't bother. Use primitives where possible, and keep your external code self contained (More specifically, contained within the "scope" of external files in general). That being said, in a language like C#, for example, where ordering doesn't really matter, that would be a different story. I'm not saying C#'s better, though, it's just a different compiler model altogether. Personally, I'm not even a fan of the language. |
   |