Extern Type
BlitzMax Forums/BlitzMax Programming/Extern Type
| ||
| v1.06 adds support for Type declarations in an Extern block. The docs give you a brief example of what you have to do, but not why. Why two padding functions for example, and why do the functions need to be virtual? |
| ||
| im curious about the padding as well since the DX mod does not seem to have the pad definitions? also, i have a Q about return types. how do you return an instance instead of a pointer? given: --- C++ --- class Ttest1{ public: virtual Ttest2* testret1(){return new Ttest2;} virtual Ttest2 testret2(){Ttest2 retval; return retval;} } ----------- i believe i would define my extern for testret1() which returns a pointer as: Type Ttest1 method testret1:Ttest2() EndType the extern typing is setup to return pointers (i think), but how do you define testret2 which doesnt return a pointer? or am i misunderstanding and my extern type should look like: Type Ttest1 method testret1:Ttest2 Ptr() method testret2:Ttest2() EndType thx :) |
| ||
| I like to know too, but one thing is certain... This addon has saved me ALOT of work. Now I won't need to break down the Irrlicht classes into callable functions, I just need to declare them with Extern Type and voila!, they work in Bmax. Luckily almost every classmember in Irrlicht is declared as virtual. |
| ||
| thats funny... im working on irrlicht as well as a learning experience :) unfortunately/fortunately i already have everything wrapped as extern functions and the core namespace (with some extras) already done as bmax types. another week or two and it probably would be ready to rumble. would you be interested in pooling resources sweenie to get Irrlicht up and running quicker? at this point i want to use the new extern typing, which means i will need to redo most everything i have already done :) but i think it will be cleaner. just need to get a few questions worked out. |
| ||
| Sweenie, gman... are you guys familiar with the irrlichtNX project... and if there is a mac port running around anywhere??? --Mike |
| ||
| not familiar with irrlichtNX red :( as for the mac version... as far as i know there still is not a mac port. also, i have been thinking and have decided to stay the course since going back now will take significant time. if all goes well with my time in a couple weeks i should have a working irrlicht mod with the irrlicht distribution samples converted. on a side note, the irrlicht mod im doing is actually broken into 2 mods, similar to blitzmax opengl support. the base mod has the irrlicht engine wrapped up and exposes the wrap functions with extern, while the second mod implements blitzmax types for the irrlicht engine. |
| ||
| Why two padding functions for example, and why do the functions need to be virtual? It is generally good practice when writing C++ classes with virtual methods to also provide a virtual destructor. I wont go into the 'why' of this, but it turns out that virtual destructors (under MINGW and MSVC anyway) actually require 2 versions - one for dynamic 'delete' style destruction and the other for static 'going out of scope' style destruction. (From memory - I looked into all this when I was learning c++ ages ago now and it's a bit hazy now). Whatever, a virtual destructor is the equivalent of 2 methods, hence the 2 _pad() methods. COM objects, however, do not use virtual destructors, so there is no padding required. As for why the c++ methods have to be virtual, this is because c++ non-virtual methods aren't actually methods in the Max sense - they are just concrete functions. And, due to c++ 'name mangling', finding the 'symbols' for such functions is tricky. also, i have a Q about return types. how do you return an instance instead of a pointer? You can't. c++ 'values' can have copy constructors/destructors and all sorts of weird stuff in them that is well beyond Max's ability to deal with. |
   |