is there a way (other than network(i hate io-streams)) to communicate between 2 process? one in c++ and other one in C# or VB.
my problem is, im writing a AVR program using c++, but for debugging purpose i need a GUI to test different inputs. since i donno anything about GUI in c++ ( and i have no plan to learn it), i want to write the GUI using .net and somehow connect it to my c++ code.
since i have 2 running process i cant use p/invoke and other similar methods. If i could share my variables between 2 process or call a function in c# from c++ (from running process to running process), that would solve my problem.
anything other than sockets?
Since you mentioned .NET you probably on MS Windows. You may use DDE (Dynamic Data Exchange):
https://msdn.microsoft.com/en-us/library/windows/desktop/ms648774(v=vs.85).aspx
You can find .NET tutorial for it here:
http://blogs.artinsoft.net/Mrojas/archive/2009/06/10/DDE-in-NET.aspx
If you want fast dummy solution that will work for you just for debugging not as real solution. You may share your data by writing them to the hard disk and reading it from it again. It is not hard neither complicated.
What about databases? if you are using MS you can try MSSQL.
Its absolutely free for small databases i think :)
Related
Does anyone have experience using the Nordic NRF52840 with a C# app to act as a receiver?
I'm trying to communicate with an Onset InTemp thermometer and although I've had quite a bit of success with the native Windows 10 BLE, I'm having some problems. See: C#, BLE. Why does GetGattServicesAsync hang forever? Is there a work around such as turning off/on BLE? for details.
Nordic advertises that they only have C++, Python and Node.js libraries. See https://devzone.nordicsemi.com/f/nordic-q-a/65516/using-nrf52840-dongle-as-receiver-client-for-onset-thermometer for example. I need either a C# library OR perhaps some hints on how to build the C++ library with Visual Studio (there are no instructions that I can see) and setup the interop layer (method signature etc.). I think this would go much faster if I saw an example :). And I'm guessing this type of work has been done before.
Another possibility is to call the Node.js libraries from C# which I understand is possible but again, I'd need some initial examples. Probably more so as I've never used Node.js either on its own or from C#.
Thanks, Dave
I have around 5 C++ DLLs which have thousands of functions and so on. So the thing is, I kind of fell in love with WPF which is in C#(as I understand). But this is another language, so after doing a bit of research I found out that I could create a wrapper, and so I did(The wrapper was created in C++/CLI). The wrapper has some few conversions, and it worked fine. I also heard about Pinvoke, but my problem with all of these is that what if I don't have time to convert thousands of functions and variables? What do i then do? Is there some kind of fast way?
PS. Im using Visual Studio 2012
Thank You
You may want to check out SWIG.
SWIG is a software development tool that connects programs written in
C and C++ with a variety of high-level programming languages.
I have C++ application which has UI developed using MFC, does some networking using sockets (using boost libraries) and some image processing. I want to move this application into Silvelight framework (I can use 4.0 if required) so that it can be used over the internet easily. Here I want to move all parts (UI + networking etc) in to C# but keep the image processing code in unmanaged C++ only. I don't know .NET framework yet, but whatever I have read so far suggests that it is not possible to call the unmanaged code from a silvelight web application. Is my understanding correct? Can something be done to achieve what I am trying to do? Also, if somebody has some suggestions on how to go about porting the code?
Silverlight 4 supports COM when running in trusted mode.
So, tecnically you could have Silverlight call your c++ library using COM.
The main problem I see is on deployment and I don't think it's a good idea.
Also, remember that Silverlight can run on Macs but COM is Windows only.
What you could do is to have the image processing happening on the server, but then you
can run into scalability issues.
Transfering large amounts of data between client and server can become an issue.
UI response should probably be closely evaluated too.
Regarding porting the code, well, you are most certain looking at a complete rewrite.
I'd suggest using WPF instead of Silverlight if possible. With WPF you'd be able to reuse your C++ as is because desktop .NET / unmanaged interop is very good (P/Invoke or CLI/C++).
Otherwise you are stuck porting your C++ to managed code, which could prove to be laborious and the resulting code inefficient.
While doing Windows Mobile development, which language should I use? C# or C++ or something else? Why one is better than others?
It depends what you're coding.
Making native calls to the OS are possible via P/Invoke from C#, but extensive use is probably easier via native C++. You'll also require C++ for using some hardware that has not been wrapped by the Compact Framework.
Most hardware (GPS, camera, etc.), is available via CF. If you're working with a Win Mobile 6.x device, you're probably better off with C#. In addition to hardware, Pocket Office's (POOM) object model is also available to C#, so you can integrate with it.
It's worth noting that most references to Windows Phone 7 refer to managed code and the possibility of Silverlight. With Silverlight in the mix, you'll have to code with C#.
Unless your app is high performance or is extremely miserly with memory, use C# or VB.NET.
Scott
It depends on task mainly.
c++ has following pros/cons:
Direct access to resources, faster programs
Can access very deep OS parts, not needed for high level applicaiton
harder to develop and requires to manage resources by developer
C#:
Runs under virtual machine (CLR), that's why is slower
Faster and easier application development
Rich build-in library
There is no right answer for this, becasue there is no one-size-fits-all "better" definition. If you know C++ and have a lot of C++ code assets already, C++ sure looks appealing. If you know c# and not C++, then C# sure looks appealing.
C++ applications load faster, but for many applications, that's not relevent. C# applications can certainly be written faster, but they also don't have determinism. I'd never even attempt a UI in C++ any longer, nor would I think about doing database access in C++. I wouldn't write a driver in C# though, or a shell extension.
Generally speaking, most solutions I've ever delivered were a mix of the two. C# has its strengths. It's fast to write, easier to debug and unit test, hard (though not impossible) to create leaks and for some operations (like data access or XML parsing) it's just easier.
C++ has its strengths too, like speed of execution (though C# can be made to go just as fast for many things), determinism and the ability to plug in to things that want native entry points.
So my answer? You need to know both, and likely write your solutiuon using both. The percentage of each you end up using depends on what your end goal is.
It depends.
At least present a specific use-case. And possibly use SO search? :)
C++ or C# to program mobile barcode device?
Edit:
Apparently others were faster to the draw, and gave more articulated answers. Nevertheless, I still recommend reading the above SO thread.
From my experience it is easier to start with c#, and if the api provided by the compact framework is enough for you then you are ok.
On the other hand if your project is somewhat complex, or if you want to do something that is not in the compact framework you may end needing to create a helper .dll in c++. Even in this case you maybe good doing your main program in c#, and programming helpers dll in c++.
If you go directly to program in c++ you may benefit from the fact that you have a raw performance better than c#, which is good if you are doing a game.
But you will also suffer more from the limitation of windows mobile OS. Like a maximum of 32MB per process, or that all .dll share the same address space.
So in the end it really depends on what are planning to do and the experience you have.
I have a solution with 2 projects:
a c++ main project
a c# project (display simulator)
Today these 2 apps share data using a loopback TCP client/server connection, but that's not very optimal (timing issues..).
I was wondering if there was a way to access the c# data from the c++ project directly and vice versa? (It seems to be possible with 2 c# projects..)
If it's not possible, what's the best way to implement this with shared memory?
thanks!
Michael
EDIT: thanks for the answers. The 2 projects used to be independant solutions and are both executables - I'm actually trying to merge the 2 into 1 solution / executable.
For info: The c++ app is a PC version of an embedded app - the c# app is a lcd/HMI simulator.
Converting the C++ project to a C++/CLI project might be the easiest way to go. Note however that some code doesn't play well with C++/CLI (we've had problems using libraries that use boost::thread in a managed executable).
You can use COM Interop or Platform Invoke to access native code in C#.
If that's not what you're asking for, please elaborate.
Named Pipes?
For interprocess communication via named pipes you can check out the .NET 3.5 feature
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx for the C# side. From the C++ side, I assume you know the equivalent :).
There are two ways I know of to get direct access to memory between c++ and c# without the overhead of marshaling/demarshaling and com. If it is required to keep the c++ part of your code native then the only way I know to achieve this is to host the clr from your c++ application. A relatively complicated undertaking. Google "hosting the common language runtime". Then you can load your c# code as an assembly, call into the c# code and provide a common shared memory style interface. Although you will have to write all of the shared memory support yourself as I have found no direct support for shared memory in c#/.net.
The other way is to compile your c++ code with common language runtime support. This is by far easier and will allow you all the power and glory of c++ while allowing access to clr based data types, and the ability to call back and forth between your c++ and c# code. See "Language Features for Targeting the CLR" in your VS2008 documentation. pin_ptr will become your close friend and ally in this process.