WPF applications are, at its core, managed applications? Right? So, I have to choose between using managed C++ or managed C#. I experimented with managed C++ years ago. It seemed to be not quite be ready for primetime. I'm guessing Microsoft has put more effort into managed C# than managed C++. So, it seems like using managed C# is the best alternative between the two. Is this the case? What experiences have you had with WPF in either language? Thanks in advance.
Managed C++ has been replaced by C++/CLI, and "managed C#" is just C#.
I would strongly recommend you to use C# for a new project, and use C++/CLI only when needed. C# has a better support, has a larger user base, and is easier to work with inside Visual Studio 2010.
Additionally, keep in mind that C++ and C++/CLI are two different languages. For my first .Net project, I chose C++/CLI because I already knew C++, and this was a very bad idea: the learning curve from C++ to C++/CLI is similar to learning C# from C++: don't fall into that trap.
C++/CLI was only really made to support writing interop layers between unmanaged code (i.e. native C/C++) and managed code. For "heavy lifting", you should definitely use C# (or VisualBasic.NET).
You can use managed C++ for your backend but, on inspection, VS (I'm using 2010 Ultimate) doesn't have any in-built templates for a C++ WPF application - only C# or VB.
I'm sure you could force it to work if you wanted to, but I'd suggest you use C#.
C# is the most used, so if you have trouble, there is more online support for C#. C# also has better support by Microsoft. It's overall just a more finished product, even now. If you really don't care yourself, i'd go with C#.
In terms of the backend, they both run on the CLR and both capable of the job. Really it just comes down to what you're most comfortable with. If you're not sure, experiment with both.
Use whatever feels most productive.
Edit:
As has just been pointed out to me though, it seems support for WPF templates (and possibly even intellisense) just isn't there for C++. So in that case I guess I'd have to recommend C#.
IMO without a doubt C# (or VB/F#).
C++/CLI is great when crossing the border of managed world and a c++ library. Complexity is higher though as subtle issues arises from the fact that one combine a managed language and an unmanaged.
Compile times are longer though as well in C++/CLI especially since the code templates are modelled after how the C# compiler works not on how the C++ compiler works.
Related
I want to use both C++ and C# in my application.
C# for GUI design and C++ for processing.
But I don't have any knowledge about this. How to communicate between them.
I don't know where I have to begin and research.
Someone can tell me the overview about this technology? And if someone have document about this topic, please give it to me.
I'm using Visual Studio 2010 for development.
Many thanks,
T&TGroup
The technology you are looking for is C++/CLI, a proprietary language extension for C++, that allows interaction with .Net code.
The basic idea is this: You write your C++ libraries as ever in portable ISO C++. Then you add a thin wrapper in C++/CLI for those C++ components you want to call from C# (or any other .Net language for that matter).
Just be aware that C++/CLI is only intended to write code for interaction with .Net. Don't be tempted to write the implementation in CLI as well, as you will end up with code that is not portable and probably a lot harder to maintain than the pure C++ version.
It depends on what the architecture of your application should be, you can for example create two different application one that is the core and another that is the GUI and communicate through messaging.
On Windows you can use Windows message queue for example, to let the two end point communicate with each other.
You can either use C++ CLI or native C++. C++ CLI is managed code and native c++ will be unmanaged by the CLR. The choice between the two depends on your usage. There are certain limitations with C++ CLI.
It depends totally on the architecture and requirement as well. You can write processing instructions in C++ (lib) use them in GUI. Can be done in VS 2010 as well easily
I have a large application written in C++, For various reasons I am going to rewrite it in C#, I have done plenty of Delphi to C#, VB to C# but C++ to C# I have never done, although I am competent in C++ I want this to be as smooth a conversion as possible.
Mainly what I am asking is what pitfalls await me in this conversion is there any key areas I should be aware of or any advice you can provide me.
This article is quite good, but is there anything else I should be weary of?
http://msdn.microsoft.com/en-us/magazine/cc301520.aspx
Main pitfall - do not think it's an upgrade. These are DIFFERENT languages, and in many places you will need complete different approach to the problems. So you should think reimplementation with minimal code reuse.
This article is decent.
I'd advice you to pay attention to the objects lifecycle.
In C++ you destroy objects explicitly when you've done with them. In C# (.NET) you don't. It can happen that an object holds on to some important resource (file handle, database connection etc.). If it is an issue, make use of the using directive.
You need to translate the spirit of the code, but not the code itself. You need to leave behind all the things you had to do in C++ because that was how it was done there. Good translation is highly creative process, so be creative.
The handling of strings was a pitfall for me at the beginning. While I Visual C++ you use pointers the methods in C# have indeed return values.
dummy = dummy.Replace("a", "b");
If you have C++ dll and you want to use them in your C# project you can used them by pinvoke and DllImport
There will be lot of differences while you will try to convert or rewrite unmanaged code to managed one. Here is a C++ to C# converter which is quite good for converting your c++ code to C# , though you can not expect to convert the whole project using it.
I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially C#).
Along the way I bumped into C++/CLI, and I want to know if there is any specific use for that language? Is it just suppose to be a intermediate language for transforming from native C++ to C#?
Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)
Yes, C++/CLI has a very specific target usage, the language (and its compiler, most of all) makes it very easy to write code that needs to interop with unmanaged code. It has built-in support for marshaling between managed and unmanaged types. It used to be called IJW (It Just Works), nowadays called C++ Interop. Other languages need to use the P/Invoke marshaller which can be inefficient and has limited capabilities compared to what C++/CLI can do.
If you need to interop with native C++, classes that have instance functions and need the new and delete keywords to create/destroy an instance of the class then you have no choice but use C++/CLI. Pinvoke cannot do that, only the C++ compiler knows how much memory to allocate and how to correctly thunk the this pointer for an instance function.
The .NET framework contains code that was written in C++/CLI, notably in System.Data and WPF's PresentationCore. If you don't have unmanaged interop needs or don't have to work with a legacy code base then there are few reasons to select C++/CLI. C# or VB.NET are the better choices. C++/CLI's feature set got frozen around 2005, it has no support for more recent additions like lambdas or Linq syntax. Nor does the IDE support many of the bells and whistles available in the C# and VB.NET IDEs. Notable is that VS2010 will initially ship without IntelliSense support for C++/CLI. A bit of a kiss-of-death there.
UPDATE: revived in VS2012, IntelliSense support is back. Not in the least thanks to C++/CX, a language extension that simplifies writing WinRT apps in C++. Its syntax is very similar to C++/CLI. The Windows Forms project templates were removed, the designer however still works. The new debugging engine in VS2012 doesn't support C++/CLI, you have to turn on the "Managed Compatibility Mode" option in Tools + Options, Debugging, General.
First C# is not a 'derivitive' of .NET. .NET is not a language, it is an application framework and class library based on the CLR, for which a number of languages exist.
That said, the most compelling reason to use .NET is that it is a well designed class library and a much easier way to develop for Windows than Win32 or MFC. However I personally decided that I'd rather learn a new language altogether than learn extensions to an old one, and because C# was designed from the ground up to work with .NET, I suggest that is the language of choice for .NET.
C++/CLI is useful is you want to use .NET with some legacy code, and I have used it for creating Windows Forms GUIs and gluing them to existing application code. Its other raison d'etre is that it is the only .NET language that supports mixed managed and native code in a single load module, so it is good for both performance and reuse of legacy code.
With respect to the number of languages, Microsoft want every Windows application to be based on .NET because it is better for the security and stability of their OS. The only way that will happen is by supporting multiple languages. Think of .NET as an application platform or OS API, and then the question makes less sense; there will be many languages for .NET for the same reason as there are many languages for any platform. Those reasons are many, including commercial advantage, application fit, politics, supporting existing developers, choice and no doubt more.
Microsoft has changed its stance on this a few times. It was originally intended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.
Then a few years ago, they realized that this simply wasn't what their customers wanted. Developers who are moving to .NET anyway generally jump to a language like C#, and the rest have reasons to keep their code in the native world, so they stay with C++.
So now, Microsoft intends for C++/CLI to be a "bridge" between native C++ code and managed code written in some .NET language. It's no longer a language they recommend you switching your entire codebase to.
It's indeed mainly intended as intermediate language to easily link .net code with native, unmanaged C++. Do yourself a favour, don't use it if you don't need to. C++/CLI syntax is a mess.
Regarding your second question ... I think today C# is the dominant language in .net, but not everyone likes its style and paradigms. .net's architecture makes adding new languages easy (see F#, which aims at functional programming).
I've used C++/CLI to create .NET API's for some unmanaged C++ libraries. Passing and marshalling of parameters takes some getting used to (depending on used types), but once you've got the hang of it, it's really a nice way to bridge the gap between the managed and unmanaged world.
I have not looked at C++/CLI but it harnesses the .NET world - think of it as a in-between C++ and C# where you have the best of both worlds. It could be useful in situations where you want to use C++ that can easily access .NET objects and it's core BCL. Have a look here at this article discussing the primers of C++/CLI. Unfortunately, I have not heard of a Managed C++ application as it has ruffled a lot of C++ friends on the syntax side of things and lost gathering of followers who went back to the unmanaged world of C++.
Hope this helps,
Best regards,
Tom.
for me, i have to use it when there is no other way to reuse c++ class
This post is old but the most important message in my oppinion is missing: You use it for being able to see and manipulate the source code of C++ frameworks you use in C#. Examples: You don't use compiled OpenCV binaries, instead you got the OpenCV sourcecode in your solution and can add simple some Extensions, or deep check how some behavior exists. Or in finanicial math you could QuantLib Sources, and so on. This is much better than having already compield libraries that act as black boxes in a lot of ways. C++/Cli in .NET solves this.
Just so you know. Unless you specify the code to be compiled as unmanaged, when compiling with CLR support it will be compiled as managed code.
While CLI C++ is nice. I find it a pain to code in. There is just something about it that makes me not want to program in it. It isn't even the "^". It is like using a broken .net. I spent 40 minutes coding something fully managed in it that took me 10 minutes in C#. I mean, sometimes I just give up and use C# because it frustrates me when coding in it. I mean if you are going to use .net you might as well use C#(over CLI C++).
I heard somewhere that Microsoft will be focusing their efforts on C# rather than C++ for the .NET platform. I can see signs of this being true because of the GUI designer that was available for C# but not C++.
So I would like to know if C++ in .NET is dying and if it will continue to be second to C# in the future.
If you are targeting the .NET framework in application development then yes C++/CLI is a second class citizen compared to C#. C# was specifically designed as the language for .NET framework meanwhile C++/CLI extension is there to allow developers to bridge native and managed code.
However do not confuse C++ with C++/CLI (C++ .NET is the same thing...). C++ is alive and well in areas such as the kernel, games, high-performance and server apps (e.g. SQL server) all of which are unlikely to change. On the other hand most .NET 'GUI stuff' won't use C++.
Managed C++ never really got to be what MS thought it would be. C# could do (nearly) the same thing, with a lot more intuitive and user-friendly syntax.
Apart from that, C++/CLI will not be left unsupported for a long time, as it's the easy way to create interop between .NET assemblies and native C++ assemblies. That's about all it's used for though (I'm sure there's a 0.001% of C++/CLI developers out there who disagree :P ).
C++/CLI is just the way Microsoft attracts native C++ developers to .NET. It was like a intermediate layer between native C++ and C#, but I'm pretty sure that developers prefer to choose either native C++ or C#.
Microsoft will not let C++/CLI die, at least in near future, however, without community support, C++/CLI will not be able to grow.
In this generation, not growing means close to dead.
I'm afraid it is.
The reason for this is not C# (which doesn't bring anything special and although it's a new language it doesn't lead in new language features but merely copies features of others - generics).
It's mainly because the first attempt of MS to enable C++ for .NET platform - Managed C++ - was a disaster.
After this they hired Herb Sutter, C++ guru, which made fantastic job designing Managed C++ replacement callled C++/CLI.
Why and how much C++/CLI design is superior to Managed C++ design you can find out by reading A Design Rationale for C++/CLI written by Herb.
By the way, Herb made vc compiler one of the best standard-conforming compilers for Windows after years of it being the worst one in regard to standard conformance.
No. It was born dead. It always has been treated as a second class citezen with no vitality roadmap.
i think YES , its dying , actually it already died ;) , coz there arent lots of people who use it , they use whether c++ or c#.
see this
I don't think it's necessarily going away, but the reason for using it almost always comes down to whether or not you need the performance benefits that come with it. If C# can do the same thing at 90% of the efficiency of C++, isn't that really good enough?
I'm not seeing any real advantages, other than the fact that you have a C++ syntax, and with it, things like pointers and destructors.
If you're talking about why you would use C++/CLI over C#, I think the main reasons are that:
it might be more natural for C++ developers (though I think this is probably not true)
C++/CLI has very nice capabilities for bridging the native and managed environments (using the 'IJW' - It Just Works - technology)
I think that Herb Sutter probably gives the best overview:
A Design Rationale for C++/CLI
If you want to know why you might want to use native C++ over C#/.NET, this boils down to why you would want a managed environment (safety, easier development) over native code (absolute control, possibly speed advantages). There are arguments for each, and the answer really depends on what you want to develop and what your market might be.
I think you're referring to C++/CLI and comparing it to C#. C++/CLI isn't a 'flavor' of C++. It's an entirely new language with entirely different standard libraries and entirely different conventions.
At work we find that C++/CLI is valuable as a glue language between C++ and .NET, but we don't use it for anything besides interface glue - C# has enormous advantages over C++ in all other applications.
If you're referring to MS C++ extensions like what Adam describes, there's no reason not to use them if they make your job easier.
the really good reason to use C++\CLI is to communicate DotNet language with Native C++, for example many companies migrate first their GUI to .Net and let some logic in C++, and C++\CLI is the good bridge to communicate beteween two techno, you can also use COM components for that, but for many reasons it's not the good choice.
I don't think comparing different flavors of C++ to each other is the same question as comparing C++ to C#. C# is a very different beast compared to the differences between different flavors of C++.