Code looks cool...

I've also done a bit of coding as well. Your code looks suprisingly similar to mine in a few places. I have coded the starting of my virtual machine. It's in tar gz format, shout if you need something else.

The code illustrates how I am going to do the binding from C++ into voodoo. There are a few things wrong with it at the moment (the returned objects aren't created at all, just using the void pointer) but they will be changed soon (using a hash lookup).

Basically each class in voodoo has a void* pointer which the macro generated wrapper methods cast into the correct data type. Integers in voodoo have their void* pointing to an int. The object created for a C++ class has it's void* pointing to the class itself.

There is no creation or deletion at the moment. Also C++ methods that have been overloaded (two methods with the same name) won't work either. I'm not sure if this is a serious problem or not, because I can't see a way around it using the method that I am without creating your own wrapper names (at least). I generate the wrapper name based on the class and the mehtod name, I can't use the parameters because they could have ugly things like "*"'s in them.

At the moment there is only one void* available for each object. What if a C++ class wants to inherit from another class in voodoo that already is using it's void*? Should I build in multiple void*'s? May be just one for each class up the hierarchy, but the wrappers need to know which one to use, unless I rewrite the wrappers to also accept the void* that they need, the vm will know which one for which method that is being called (I think?)

The macro way of defining a wrapper is not the only way to write native code, you can also just register a user written method normally as long as it takes (voodoo::vm_object*, voodoo::vm_object**) as parameters and returns a voodoo::vm_object* even if it is null. The pushing and popping of parameters is done automatically by the vm. Using the non-macro way also allows you access to the actual vm_object's so you can do tricky stuff, like implement the fine details of the voodoo api.

What do you think, does it look workable?

[Edited by - umbrae on December 4, 2004 9:01:34 PM]

i only had a quick look, because i have only a limited amount of time, but one thing, you should edit, occured to me:
instead of using (vm_class**)malloc(0) and free you should use classes = new vm_class*[0]; and delete[] classes.
this way you stay on the c++ side of things.
concerning my post, if i try to write the INT macro into multiple lines with \ the gamdev forum converts it into one long line, so i will just delete this line.

Thanks a lot. I wasn't sure how to do it in C++. I suppose you can use it like realloc as well? I will have to do some playing around.

I think your _XVM_INT_OP(__name__, __op__) macro is doing the same thing in your first source code...

I don't think gamedev's software should allow escapes, although it looks like it does.

no, the _XVM_INT_OP(__name__, __op__) macro, is simply a way to define an integer operation opcode, since it is always the same code except the operator wich is changed, i thought using a macro doing all the work for me would be a clever idea ;).
_XVM_INT_OP(__xvm_iadd, A + B) expands to something like
xvm_bool __xvm_iadd() { uint A = stack_top[-1]; uint B stack_top[-2]; stack--; stack_top = A + B; }
(just pseudocode).
but my INT macro split an integer, into four single bytes and depending on it sign, it did a conversion to the 2's complement format used by many proccessors for integer arithmetic. it is also much nicer to write something like PUSH, INT(3), instead of PUSH, 0x00, 0x00, 0x00, 0x03 - especially when the number is negative or greater than 0xff.

Yeah, I noticed that - good work.

What I was meaning was that it has no line breaks either. :P

i just fixed a stupid bug in my smart pointer class, wich prevented me from going on with my project - it is really annonying if everthing ends up in segmentation fault.
but i don't know if this was a bug in my code or the compiler. the template code didn't work but the one without templates did.

i think the compiler was just too stupid to figure out that any_pointer<String>::any_pointer(const any_pointer<String>& ) is just the same as any_pointer<String>::any_pointer<String>(const any_pointer<String>&).
but as i said the bug is fixed so i can finally continue working on my compiler.

I have had no success at having a templated class prototype in a header, the implementation in a source file and then linking to that class. The compiler always complains. I suppose I should really post this elsewhere as well, but ...

Not sure if this is my error.

If you have the source in the header file (ie each source file actually has the source) then it works. But this is really annoying because it means that the code is duplicated everywhere.

Edit:
It seems that there is no solution other than to create the definitions of the templated classes that you want to use. C++ is really about as static as you can get for a language that has dynamic parts :S

main.cpp:
header.h:
template.cpp:

[Edited by - umbrae on December 11, 2004 5:52:47 AM]

currently no mainstream compiler supports the seperation of implementation and declaration with templates, i think the comeau compiler supports it.
but normally you have to put everthing in the header.