In the past I've either made a. C wrapper for my C++, which I've then wrapped in C#, or I've wrapped my C++ in C++/CLI, which makes it usable in C#.
However, recently I had to do a job that required calling x64(64bit) C++ code from an x86(32bit) C# program - the standard solutions don't work in this situation!
So instead, I made two processes - one C# x86 and one C++ x64, and had then communicate via a Win32 pipe object (wrapped in a binary reader/writer on the C# end, and just using the Win32 API on the C++ end). It turned out to be really simple and I actually enjoyed using the network-esque style of communication.
One advantage of this is a kind of crash isolation / sandboxing. If your C# GUI crashes, then the core engine par of your editor is still running and you haven't lost any data - you can just restart the GUI.
Insomniac do this with their tools, with the core editor logic runnin in an engine process, and the GUIs actually running inside your web browser!
How to communicate between c++ and c#?
So instead, I made two processes - one C# x86 and one C++ x64, and had then communicate via a Win32 pipe object (wrapped in a binary reader/writer on the C# end, and just using the Win32 API on the C++ end). It turned out to be really simple and I actually enjoyed using the network-esque style of communication.
I did something similar for my debugger:
AnyCPU C# WinForms app <-> named pipe <-> Hybrid C# & C++/CLI debughost processes (one targeting x86, one x64).
Each debughost process is primarily C#, using the same named pipe C# DLL that the WinForms app used, which eliminated needing to write the named pipe code in both C# and C++. Each debughost has its own 32-bit or 64-bit Win32 debugging code written in C++/CLI to do the actual debugging, and a really simple C# glue to bind the named pipe code and C++/CLI code together.
This allows one instance of the GUI interface to debug both 32-bit and 64-bit processes at the same time. I was initially a bit worried about performance, but it can transfer data at over a gigabyte per second, which is far more than I need.
There are certain obstacles about c++/CLI . You are unable to (or rather strictly soudn't) pass pointers of memory from C# module to c++ module, so you must think well about the CLI wraper you are to write and use. If you do interchange memory , you will screw yourself up with "unsafe" keyword, making C# actualy unsafe language again. CLI will force you to a very intensive isolation on the other hand, what is good, yet, you will have to clone memory/data you pass from C# to c++. The memory c++ module uses, must be allocated by this module, C# will only instruct the values to use in it. If you are a good programmer, your CLI module will be just perfect, but you should definitely know and learn CLI vitals. Not every c++ module has a good wraping "score", in such cases, you wrap only user-data-unoperating functions, zombie/initialization functions, and rewrite the very user data operative functions to the actual C# (what CLI module offers itslef). CLI is actualy code that can operate on C# memory (and types), and operate on native memory (and types), to allow one invoke deeper c++ modules instructions, while keeping distinction between those memories and its managing.
In the past I've either made a. C wrapper for my C++, which I've then wrapped in C#, or I've wrapped my C++ in C++/CLI, which makes it usable in C#.
However, recently I had to do a job that required calling x64(64bit) C++ code from an x86(32bit) C# program - the standard solutions don't work in this situation!
So instead, I made two processes - one C# x86 and one C++ x64, and had then communicate via a Win32 pipe object (wrapped in a binary reader/writer on the C# end, and just using the Win32 API on the C++ end). It turned out to be really simple and I actually enjoyed using the network-esque style of communication.
One advantage of this is a kind of crash isolation / sandboxing. If your C# GUI crashes, then the core engine par of your editor is still running and you haven't lost any data - you can just restart the GUI.
Insomniac do this with their tools, with the core editor logic runnin in an engine process, and the GUIs actually running inside your web browser!
I always liked the idea of embedding a web server in your engine
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
