a few questions
I prefer to be brief about this because last time I went into detail and got auto-logged out and lost everything.
- Is NGen (native image generator) in .NET 4.0's SDK? I don't have Windows at the moment so I can't see for myself. I can only find a 5 year old version of it from .NET 2.0.
- I'm aware of the field offset workaround for union types in C#, but if I'm doing this on 32-bit, would 64-bit introduce flaws for a compiled assembly?
- Does Microsoft's C# compiler suppoert ahead-of-time compilation as opposed to just-in-time, like Mono's compiler does? I seek to maximize performance if possible.
- Would an unsafe block work if I need a pointer to a value type instead of the value itself? There are some cases like file format implementation where this would be needed, for example.
Use C++/CLI to mix managed and unmanaged code. Unsafe blocks are not needed.
I actually did look into that. The problem is Mono does not support mixed code and I wanted to target Unix AND Windows. I'm nervous about how many people I'd be cutting off if I drop Unix support. I know WINE can remedy that, but only to an extent. Compatibility and usability vary from release after release I've read. My main interest is RPG development and I do not know how well XNA would run through WINE, if at all.
Mono does not have to support mixed code. I have been working on projects that use Mono as well as C++/CLI and C++. Works fine. Not sure how you would link under Unix as I'm not familiar with it. In Windows you just use DLLs - managed and unmanaged.
Well a while back when I was a Free Pascal nut, I read an article in their wiki on how to use .NET with it, like a one-way FPC-to-.NET but not the other way around. The trick was if it was a dynamic library, rename the extention to .dll instead of .so or .dylib.
I wonder if the same applies to C++. The problem would be doing two-way interraction, because I want to call .NET from C++.
I'd do conditional macros, but my dilemma is I want to utilize .NET's API.
EDIT: Just found this: http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx
Now I just hope field offsets won't overwrite memory in different endian/bit systems. Is there a list of preprocessor symbols Mono or .NET has? Google makes this difficult and I want to make sure my programs will be ok.
It is very simple to call C++ from C# and vice versa.
You might want to look into msclr::gcroot and msclr::auto_gcroot. Using these a ref class in C++/CLI can maintain a pointer to an unmanaged class. Ref classes are managed classes and can be referenced in C# and used just as if it were a C# object. This is b/c C# and C++/CLI ref classes are .NET objects and thus can talk to one another.
C++/CLI ref classes also can contain references to managed objects or C# classes/objects. With all of this you now have the ability to communicate from C++ to C# through CLI and from C# to C++ through CLI and yet do not have to do any ugly P/Invoke declaration garbage in C#. This method only requires some interfaces and a small bit of C++/CLI code and it all works and is completely transparent to C++ and C#.
C# ----> C++/CLI ---- via pointer in msclr::gcroot<> ----> C++
C++ ----> C++/CLI --- via reference to managed class ----> C#
The big catch here is you want to use .NET data types in the interfaces of the C++/CLI methods/functions. There are also simple ways to convert from System::String to std::string and vice versa. Most System namespace datatypes will be martialled correctly to C++. Bool is a bit odd and I invite you to Google it to find out why. You can also convert from System::List to std::vector with a little bit of code. Keep in mind that a C++/CLI ref class cannot have an instance of an STL container or data type but it can make use of them in its various methods.
The usual paradigm for doing this is to startup the C# code. It then calls out to the C++/CLI code which then instantiates the C++ side. This can also be done in reverse order if need be since a ref class can both use, instantiate, and maintain managed class references. These cannot be returned to C++ but they don't have to be b/c the C++/CLI code can do all the heavy lifting and yet still talk to pure native C++. Absolutely beautiful if you ask me. Using this type of system I can fire events in C++, listen for them in C++/CLI, and pass them on to a managed listener in C#.
Ah, I think I get the idea now. Though, C#'s idea of interfaces as opposed to multiple inheritence kind of disappoints me. It's particularily because of field inheritence. I guess the workaround if to have reference variables for every multiple class I'd want to use a variable from. Except the following code would be rather... burdenous:
The intention of this example is completely random, but if I wanted to make a pegasus from a bird and horse and use the 2 parent class variables, the above would be cumbersome. I could always derive Pegasus from Animal, but I'd have to copy and paste everything from both classes into Pegasus, and even then it wouldn't be allowed to be placed into an array of Birds or an array of Horses.
pegasus.bird.animal.organism.thing.spaceOccupied = 5;
pegasus.horse.animal.organism.thing.materialized = true;
I may have gotten mixed up on the use of gcroot. It's been a bit since I've messed with this kind of code. However, the concept is the same. I invite you to research into it a bit and implement it how you see fit. gcroot allows an unmanaged class to have a pointer to a managed class. I have it backwards in my first post about this.
If you still have difficulties with this I would be glad to assist you with this. There are more and more sites that are starting to talk about interop so you should be able to find some good information. Some of it is old, however, and often relies on some pretty nasty approaches to the issue that had to be taken before C++/CLI was updated to be a bit more friendly in this area. The old approach to interop was through COM and creating COM objects which does work but is very nasty and not all that intuitive.
Well, for now I'm keeping my fingers crossed on my next PC I'll be getting in August. I have really high hopes about 'ngen'. So, I might start a new topic on this in a few months if ngen turns out to be... not what I expected.