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?
Related
Good afternoon,
I thought about writing an application which I may or may not commercialize, depending on how good the final application is. It is like a personal project, with which I hope to learn many more things about programming, for currently I only know most about C and C#. That's why I thought about starting this project as an unmanaged C++ Win32 application. The problem is that it is most dificult to even show a simple window when compared to C#...
How many people/companies use the Win32 API & C++ in today's business world? How does it perform in comparison with C#?
The application in question may eventually be an IDE for a specific language but whith features like command recognition and spell checking already built in.
Thank you very much.
It seems that when performance is needed people are willing to give up C# for C++.
Have a look at this "success" story Lessons from Evernote’s flight from .NET.
On our test hardware, Evernote 4
starts five times faster, and uses
half the memory of Evernote 3.5.
Evernote chose WTL and Chromium Embedded Framework. Basically they've reused Google's Chrome in their application.
For your first project and w/o prior C++ and Win32 experience, I would STRONGLY recommend you use the C# , as it will be easier for you to get something done thereby gaining confidence and skill as you go.
I'm a huge fan of C++ under windows, I've been doing it most of my adult life. That said, if you have no experience of C++, and you want to write a windows application, I'd suggest going with the C# route under .NET. Whilst I love native C++, I really disliked C++/CLI, and the horrid ^ suffix for references.
Given this is a personal project, I wouldn't worry too much about whether businesses use C++ or C#, but I will say that it is easier to find a C# developer these days than it is a C++ developer. And no, I am not favouring one language over the other here, it just appears to be the reality (at least in my experience). As for C++/CLI developers? They're kind of thin on the ground :)
You'll definitely be up and running faster with C# than you would with Visual C++/MFC/some-other-gui, but remember there are certain things you may not be able to do in C# (and have to import the native win32 calls via DllImport), but I doubt you'll come across these fringe cases just yet.
C# is the easy route, and the route most-often pushed by Microsoft. What they don't tell you, though, is that all of their headline products (parts of Visual Studio excepted) are written in C/C++. I'd say, in fact, that most major software packages you are familiar with are written in C/C++.
I'd go with c# too, as it is far more common in a business world (on GUI side at least), than unmanaged c++/win32. You'll also get your desired results faster, especially if you don't know c++.
On the other hand, c++ performs better (if written properly) - so if you are planning some intensive work in your app - maybe c# just won't handle it (but I strongly doubt this is the case).
At last, but not the least - if you are planning for clients, that for some reason do not have and can not get .NET framework (or any other framework, i.e. Java) - then native code is your only solution.
I have only been using C++ for quite a few years, but I have never had to write any programs which required a User Interface. When I did, I tried to learn to use Qt, but found it to be somewhat of a pain and eventually gave up. I recently just started taking a class on C# .NET and in the first week I have already started developing a pretty advanced application for my companies billing system.
If you were already a seasoned C++ veteran and preferred it over C# .NET, then I would say by all means go for it. In this case however, I would strongly recommend you go with C# .NET for quite a few reasons.
1) The time is takes to do something in C# will probably be at the very least about 10x faster than doing it in C++ regardless of the API you used.
2) The learning curve of C++ on top of already trying to write an application with a UI (which is already very difficult in C++) will make this take an extremely long time.
Or I should ask how helpful and benifitial will it be to start with C++
This may seem irelevant but it has some significance for me,may be few others like me.
I just want to know ,How Important is it to Learn C++ , COM and ATL while you are a .NET programmer?
I love programming with .NET and C# .Visual Studio just has it's own charm of intellisence ,Color Coding and other pretty features , which make us addicted to it.
I was thinking , almost we can build anything with C# and still it holds true mostly, but it lags sometimes like:
While I try to create a Shell Extension , then it is highly suggested to use unmanaged code instead of any managed code.
Also there are few other things like COM , ATL , which are preferred to be coded in C++ rather than C#.
I am just 4 years in IT industry and love to be Solution Architect.
So need all your inputs to know , how important/helpful will it be in my future venture if I am doing my Current COM Project with C++ , which integrate with .NET UI.
Is there any implementation of C++ and .NET in common domains like Health Care, Banking and Telecommunication.
The issue (at least for the specific cases you mention, such as shell extensions) with trying to "integrate with a .NET UI" is that you really can't. The reason it's not a good idea to write shell extensions in managed code is that a given process can only load one version of the CLR at any given time. If two shell extensions depend on different versions of the CLR, and they both try to load at the same time, it will fail. You can't load the CLR in any way shape or form in the context of your shell extension and be a well behaved shell extension.
My advice would be to not bother with C++ until you really have a reason to learn it (despite that C++ is my favorite language). But when you do learn C++, leave your .NET baggage at the door. There are lots of things (such as excessive use of casting, constantly using new, etc) which are idiomatic C#, and are just plain wrong in C++. You will be a lot happier if you don't try to understand C++ concepts in terms of the CLR -- simply because C++ doesn't run there. You can use some of the design patterns you may have learned for C#, but how the underlying language and machine operates are completely different between the two languages.
Probably the most confusing difference for new C or C++ programmers is the concept of undefined behavior. The C and C++ standards are written in such a mannar as to not be tied to a particular machine. This is in stark contrast to architectures like Java or .NET, where the language is actually defined in terms of a virtual machine (and therefore is extremely dependent on that VM). This leads to places where the standard literally does not say what the correct output of a program should be; and instead says "however the underlying machine usually does this". You'll probably notice this quite a bit if you're ever dealing with floating point math. While C# has strict and specific rules about how and where floating points are calculated and rounded, C and C++ make no such qualifications.
Once you understand C++, then you can move on to COM and ATL. COM is essentially designed to make a C++ like class structure accessible in a language (the COM ABI), machine (marshalling between 32 bit and 64 processes on the same system, etc), and location (DCOM provides RPC facilities) independent way. If you don't understand the C++ object model, then you're going to have an extremely difficult time with the COM object model, because the two are extremely similar. ATL is a set of C++ class templates around COM fundamentals which simply handle some of the boilerplate for you.
I just want to know ,How Important is
it to Learn C++ , COM and ATL while
you are a .NET programmer?
Depends what you do. You are way better of learnin about databases. Pretty much every serious app uses a database.
But C++ IS ued together with .NET - especially C++/CLI (the managed variant) as it is very good for integrating C++ code with managed code effficiently. Quite often pretty much the only efficient way. Which is important if you for example raise events for market data. With a frequency in excess of 100.000 times. Per second.
But this is a NICHE. I work in the financial area, and tthe C++ uses AND integration uses are SMALL compared to the people working in .NET / In the application.
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.
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'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++.