c++ .net or c# .net

Hi all,

Just a quick question to the experts. Im currently an embedded c developer and i now want to write a few windows programs (for windows and portable devices) that i can communicate to my embedded systems via the serial port, blue toooth, and hopefully over networks. Which is the most easiest to use/ most powerfull in bit manipulation, numerical analysis and talking to hardware devices out of c++ .net and c#.net?

Cheers Tuurb046

I'd expect them to be pretty similar. C# is sort of a superset of C++, with only small amounts removed.

But a lot depends on exactly what you want to do.

--
Mats

1) Neither C++.Net nor C#.Net exist. The former is called C++/CLI, the latter just C#.

2) C# and C++/CLI are completely distinct languages. They only share origins: C# is a C++-derivate similar to Java, whereas C++/CLI is a true superset of C++, designed to accept all plain C++ code as valid. Thus, they have similar, but not equal, syntax.

3) The best for the three topics you listed is plain C++, because it is low-level enough for talking to hardware devices and ought to be the fastest in numerical analysis and bit manipulation.

4) C# is best for high-level application programming under Windows.

5) C++/CLI is a bridge language, designed primarily to connect C++ (and other natively compiled) components to .Net languages like C#.

Hi,

Thanks for all your help. Just one last question, can i write c/c++ source files and link them into a c# program (i think these are called dll ?). Or is this the point you use c++/CLI?

Cheers tuurbo46

You can use C and C++ DLLs from C# via the P/Invoke facility. That requires that the functions adhere strictly to the portable DLL call interface of Windows. (STDCALL and no funny C++ stuff like references.) Also, you'll have to write a .def file to get the exported names as you'd expect them.

Frankly, it's a lot easier to just use C++/CLI for the bridge.

On the other hand, P/Invoke works under Mono too, while C++/CLI hasn't yet been implemented and will probably take a long time. (Until GCC can generate proper CLI, at the very least.)

Quote:

---

...communicate to my embedded systems via the serial port, blue toooth, and hopefully over networks.

---

That's usually going to require a driver, and I assume the Windows DDK (Driver Development Kit) uses C/C++. (You'll probably need a user-interface program and a driver.)

On a PC, Windows blocks user-mode programs from directly accessing the hardware, so you need a kernel mode driver. I'm not sure if this is true with Windows CE on portable devices.

You can open the serial port without using a driver, and if you are using TCP/IP, you might be able to get-by with the existing Windows TCP/IP driver stack. However, I suspect bluetooth will require you to write a driver. I don't know anything about bluetooth, but I know USB requires a custom driver, unless you are interfacing to something standardized... like a USB keyboard or USB mouse. Some devices (i.e. printers) require a driver no matter what the interface.... Just because you can open the serial port without a driver doesn't mean it should be done "the easy way".

Quote:

---

for windows and portable devices

---

When it comes to portable devices, your choices of language/compiler will be limited in the same way you are limited for embedded development. You have to use whatever compiler/languages are available for the particular device.

Quote:

---

Originally Posted by CornedBee

4) C# is best for high-level application programming under Windows.

---

btw
C# for non Windows -> mono