If you had to decide between C# and Managed C++, which would you choose and why?
Are there benefits of Managed C++ over C#? Which language do you prefer? What decisions would you make under what circumstances?
I would use managed C++ if I:
Needed to integrate with existing C/C++ code
Needed to port existing C/C++ code to .net
Needed to use .NET objects from C++
Needed to expose .NET object over COM in a more complex way than what .net makes easy
Needed to access hardware directly
Needed to call lots of unmanaged APIs
And already had some skills in C++, as the above tasks will need a experienced C++ programmer. Most of the time I would only consider managed C++ if the company already had a C++ code base, otherwise who is going to maintain the managed C++ code.
In other cases I would always choose C#. Even if I choose managed C++ for part of the system, I would try to write as much of the system as possible in C#.
Think of manage C++ as a bridge building kit for going between the
unmanaged world of C/C++ and the
managed world of .NET.
If you only need to call a few simple APIs from C#, then see pinvoke.net and this overview to find how to call them from C#, as a few lines of complex pinvoke code (prebuilt bridge) in C# is normally better then introducing C++ to a project that is not already using it.
what is the benefit of managed C++
over C#?
C++.net is useful for interacting with C++ and C code (that is, calling external C or C++ libraries, providing callback functions to external modules written in C or C++ and so on.
what language of both would you
prefer?
I would prefer C# for all situations except the one described above (interacting with C and C++).
C# is easier to write, simpler, and geared specifically to use the .NET platform. C++ can do it also, but it has all the complexity of the C++ language plus the extensions needed to use the .NET platform.
Unless you need to interact with native C++ or C code, you're better off using C# in most cases (that is, if you're coding for the .NET platform).
Normally I prefer C++, but when needing to code for .NET, it doesn't beat C#.
Managed C++ is good for interop with C++: for example, if you have a .NET application and your assembly has to interact with a native interface that comes as C++ .lib files (which I had more than once), or with a nice C++ API.
Example: Rithmic (not that you ever heard of them) until recently ONLY supported a C++ API. If you try to access them from C# - good luck ;) Managed C++ allows me to access their API and expose nice .NET objects.
Basically interop. Managed C++ REALLY shines in interop with low level C / C++ API's.
I used managed C++ when I needed to build up new NET component with much ofC++ unmanaged code inside.
I did a specific class used to Marshall some objects forward and back from old C++ code.
I've encountered a problem which was transparent in managed C++, but made a big headache in C# - I had to send a callback function to a C++ unmanaged library, that defined this callback as __cdecl. In C#, the default calling convention is __stdcall, and it is pretty compilcated to move a C# delegate from __stdcall to __cdecl (Actually it requires either a 'shim' unmanaged DLL to do so or using some reflection classes).
In C++, (C++.Net as well), it is just a simple attribute.
I haven't personally written, or read for that matter, too many lines of code in managed C++, but from what I have seen it looks too convoluted and patchy. That said, you might want to use managed C++ if you are really good in C++, and when learning the idioms and patterns of a new language would be too much of a risk.
Use C# if you are quite competent in it. If you are only getting started with C++ and C#, I think, C# is the easier route to take.
I would prefer C#, or specifically .NET, over C++ because of the extensive .NET standard library.
Related
I need to write a couple DLLs that will both be accessed from a C# application and a C++ application. Initially, I was thinking that I could save time/effort by writing the DLLs in C# and linking to them from the C# and C++ applications. Is this approach wise, or should the DLLs be written using C++?
My advice would be to implement the code where you are most comfortable, but don't forget the interop requirement as you go. Know upfront what your interface is and what glue is required in the end product. Write the interface and test the interop before you fill out the implementation.
If the complexity of your requirement makes comfort level irrelevant, I would write it in C++ in such a way that you can access via P/Invoke.
One important factor is are you using C++/CLI or native C++. It's a lot easier to interop between C++/CLI and C#, in either direction.
I suggest you write your DLLs in C++, expose their public classes to COM using ATL or similar, then have tlbimp generate a thin C# wrapper around the COM interfaces.
If the DLL is to be used in other .Net applications, then you are pretty safe writing it in C# or C++, whichever you are more comfortable in.
If the DLL is to be used elsewhere, you will find it easier to write it in C++.
In the course of finding a way to interoperate between C# and C++ I found this article that explains about P/Invoke.
And I read a lot of articles claiming that C++/CLI is not exact C++ and requires some effort to modify from original C++ code.
I want to ask what would be the optimal way when I have some C++ objects (code/data) that I want to use from C# objects.
It looks like that in order to use P/Invoke, I should provide C style API. Is it true? I mean, is there a way to export C++ object to C# like SWIG with P/Invoke? Or, do I have to use SWIG for this purpose?
How hard is it to change C++ to C++/CLI? Is it worth trying compared to rewrite the C++ to C#? The C++ is well designed, so implementing it to C# is not great deal.
(Off the topic question) Is there the other way round? I mean, if I want to use C# code from C++, is there any way to do so?
I would not recommend rewritng your C++ library into C++/CLI. Instead, I would write a C++/CLI wrapper that you can call from C#. This would consist of some public ref class classes, each of which probably just manages an instance of the native class. Your C++/CLI wrapper just "include the header, link to the lib" to use the native library. Because you have written public ref class classes, your C# code just adds a .NET reference. And all you do inside each public ref class is use C++ Interop (aka It Just Works interop) to call the native code. You can apply a facade while you're at it if you like.
The C++/CLI syntax is awkward, but it does allow you to expose managed objects from C++ code. This can be convenient if you have a large C++ API and can abstract some of that functionality to a simpler interface for consumption by your managed code. I've done this successfully for integration with tools like the Matrox vision library, where I could write my vision analysis code in C++ and then use the C++/CLI extensions to expose high-level managed classes. The most painful part is probably string and array inter-op, but strings have always been painful, even in plain C++.
C++/CLI can definitely consume any .NET managed objects, but you have to take special care if you're using any pointers to managed memory (you'll need to use pinning in this case.) If I need to pass pointers to an API, I usually prefer to keep that memory unmanaged and then create managed wrapper classes for manipulating the unmanaged memory.
Further to Kate Gregory's answer, to call C# code from C++, using C++/CLI is the obvious way to do it, as it makes it extremely simple and seamless.
Wrap your C++ native classes, as pointer to implementation, into C++/CLI classes, then call & use these CLR-based classes by 'using'ing them in your .net application. This is my recommended way. DO NOT REWRITE your existing classes in C++/CLI.
I have a native C++ DLL using DirectX, that I want to be able to use through C# to be able to create content creation tools.
Adding COM would require quite an effort it seems.
Can P/Invoke be used to maintain classes using polymorphism, or would it require me to wrap most of the code to facilitate use of P/Invoke?
It there a better solution is available? Or should I even consider writing the tools in C++ using Qt perhaps?
I always feel that C++/CLI is always the best option when doing C# to C++ interop. You can easily create thin wrappers for an unmanaged library that will look exactly like a managed library to your C# code. It also gives you more control over how marshaling and pinning is performed.
There are ways to automatically generate C++/CLI I believe, but I've never used them.
More info on C++/CLI here:
http://msdn.microsoft.com/en-us/magazine/cc163681.aspx
I presume rendering with D3D directly from C# isn't an option? (because that certainly would be easier!)
A long time ago, I used SWIG to automatically maintain C# "bindings" of my C++ rendering DLL code. It uses P/Invoke to expose the C++ objects on the C# side, and you won't have to maintain that code anymore.
You don't need to write wrap on QT.
I advice you to write Observer class both in C# & C++, and hide calls of Native functions to it.
Schema is like this
Your code in C# -> Observer(C#) -> Native call to Observer(C++) -> Calls to your dll.
Is there any major advantage of managed C++/CLI over C#. Definitely not the syntax I suppose as the following code in C++/CLI is real ugly,
C++/CLI code:
[Out]List<SomeObject^>^% someVariable
Compare above with C# Code:
out List<SomeObject> someVariable
Just out of curiosity, is there an even uglier syntax in C++/CLI as compared to the above.
It's almost exclusively an interopability language - both for allowing .Net code to access legacy C++ libraries, or for extended existing (native) C++ code bases with access to .Net libraries (and some variations on these themes).
While it is possible to write fully fledged applications solely in C++/CLI, and it even gives you some language features not available in pure C++ (such as garbage collection), I doubt there are many people who would actually do this. If you're already moving away from pure C++ and don't have the goal of interop with .Net there are probably more natural choices (such as D or Scala, for example - depending on which direction you want to go in).
Similarly, moving from pure C# to C++/CLI could arguably bring the advantages of C++ templates, but it's rare that this need would lead to you taking that step.
Easier interoperation with native C++ code is the one advantage.
Whether it's a major advantage is subjective.
Unless you want to mingle with existing native C++ code, you're probably much better off with C#.
I can think of 3 main reasons to use C++/CLI:
You already have a large C++ project and want to use .NET in it (whether you want to migrate it completely in the future or not)
You want to use a library written in C or C++. For simple libraries, you can use C#/PInvoke, but e.g. if the libary comes with a complex type system, you might be better off creating C++/CLI wrappers instead of recreating the type system in C#
Parts in your project are best written in C++. E.g. if you're doing speech recognition or image processing, C++ might simply be better suited for the task.
Being able to use native headers files directly is a huge advantage, but not the only one.
Stack semantics are so much better than anything C# has to offer for IDisposable management. C++/CLI has one uniform syntax for correctly managing variables which are IDisposable and those which aren't, both as local variables and as member fields. Comparison:
ref class MyClass
{
FileStream fs;
}
vs
class MyClass : IDisposable
{
FileStream fs;
void IDisposable.Dispose() { Dispose(true); }
~MyClass() { Dispose(false); }
public virtual void Dispose(bool disposing) { if (disposing) fs.Dispose(); }
}
Now which language is looking ugly?
Then there are templates, interior_ptr, #define, native DLL exports, pointer-to-member, and probably several other things I've forgotten.
Using C++/CLI it is much easy to interact with native C++ code
The advantage of managed C++ is that it is easy to mix managed and unmanaged code. But if all (or almost all) of your code will be managed, then C# should definitely be used (and you can still invoking unmanaged code from C# using the DllImport attribute).
CLI/C++ has many advantages over C#.
STD libraries
Native C++/C cannot be viewed by disassembler (like Reflector) because they are not actually CLI (no need to obfuscate (although a good hacker can already get by this)).
Mingling C/C++ projects as a wrapper to be used with .Net languages. C++/CLI is not a language is just adds support for .Net with C/C++.
Some bit of control on memory via C/C++ pointer pointing to C/C++ objects on the heap.
I hate having to trust in GC to get to an object stuck on the gen 2. Lord knows when that will be released from the managed heap.
Being a predominantly C# programmer, I was finding myself having to use C++/CLI with a bit of pain. However, as an interop language, it FAR outweighs C# for having to work with native code. The C++/CLI IDE in Visual Studio lacks a lot of the features in the C# flavor.
Overall, it has its place and will remain viable as long as native code exists. I wouldn't want to have to create WinForm apps from scratch with the C++/CLI IDE if I didn't have to.
you just turn to c++\cli when you have to, if you can meet you requirement using c#, why bother go c++\cli
Generally, I think the main advantage of C++/CLI is simply familiarity for C++ developers. If you're not coming from a C++ background then go with C#.
unmanaged c++ applications do not need a framework to run, c# will only run on machines with dotnet framework 1, 2, 3 or 4. it surprising how many machines still run without these framework.
People always advised me that if I am doing some application that should use some Windows APIs to do any process level job, I must use VC++ and not any other .net language.
Is there any truth in that?
Can everything that can be done using VC++ be done in other .net languages also?
Are all the .net languages the same when their capabilities are compared?
If you need to work with native code fairly intimately, C++ is likely to make life easier. However, there's nothing inherently wrong with using P/Invoke to call into the Win32 API from C#, VB.NET, F# etc.
Not all .NET languages are the same in terms of capabilities, although C# and VB.NET are largely equivalent in functionality. I know there are some things which C++/CLI exposes which aren't exposed by C# or VB.NET - I don't know if the reverse is true. (I've no idea what C++/CLI is like for lambda expressions, extension methods etc.)
For most tasks where the class libraries do not provide help, using P/Invoke is usually fine. There are many "rough" APIs out there that benefit from a simple C++/CLI wrapper. It's usually best to do the bare minimum in the C++/CLI code -- effectively massaging what ever ugliness is below for consumption by C#, VB.NET, etc.
When I started programming in .Net, I was using C++/CLI, as I came from a minimal Win32 C++ background. What I found was that I was getting headaches because I didn't understand the fine lines and boundaries between C++/CLI and Win32 C++. Its not as easy as they make it seem to interop between the two. When I learned about P/Invoke, and made my life much easier, and I finally started to progress my skills. P/Invoke is just fine and you don't necessarily need C++/CLI to do that. In my opinion, you either use Win32 C++ completely for low level stuff, or .Net for high level stuff, and I don't really recommend ever trying to interop Win32 C++ with C++/CLI unless you absolutely have to. Even then, its probably just easier to make a Win32 DLL with what you need and P/Invoke the DLL from .Net, or visa versa. Always remember to pick the right tool for the job.