Semi-newbie question on Visual C++ vs. Visual C#
in [MFC]
|
From: Larry Smith on 11 Feb 2007 17:22 > Bruno, since I have over 15 years of C++ experience, I'm finding the > easiest way to do WinForms is with VC2005 C++/CLI. Other than the tools > like refactoring, what does C# buy you that C++/CLI does not have for > building WinForms apps? > > I like the ability to just call my native C++ classes as usual. I had to > write a CNativeString class to marshall C-style strings to .NET String but > that's it. No PInvoke, no nothing, just call the native C++ class. > > I will eventually learn C# because the ecosystem of .NET seems to revolve > around it, but I don't see why C++/CLI would not be a first choice for > WinForms coming from a C++ background and with a high priority of > interfacing to native C++ code. > > Thanks, > David (MVP) David, I''ve been programming in C and C++ for almost 25 years. :Last year I started working on my own commercial app for .NET and had to decide which language to go with. I really didn't want to go with C# but felt I had no choice. C++ has been bastardized to work under NET and I don't think most developers in the real world would choose it for that environment. C# is more natural for .NET and much easier to learn for new developers (a breeze for C++ developers). As a result, I think that C++ is now in serious decline in the Windows world. It will simply be much easier and far more cost-effective to support a C# app going forward as .NET becomes the main platform for Windows (if not already) and the number of competent C++ developers dwindles (noting that there have always been relatively few competent C++ developers anyway). In fact, it seems to me anyway that most of the Windows development community is now re-tooling for .NET (or sooon will be) and C# is clearly going to replace C++ in most shops. The unfortunate thing is that while both languages could benefit from each other in some ways, C++ is still a superior language IMO. I'm constantly finding myself dealing with issues and problems in C# that I don't experience in C++. That's another topic however but in the end I think that sticking with C++ under Windows is a lost cause.
From: Joseph M. Newcomer on 11 Feb 2007 23:07 I'm not seeing much change to either C++/CLI or C#. Which I find a bit odd. Besides, I'd like to use C# more often. I find it a pleasant language to program in, even if the editor is something out of the 1950s. joe On Sun, 11 Feb 2007 17:22:09 -0500, "Larry Smith" <no_spam@_nospam.com> wrote: >> Bruno, since I have over 15 years of C++ experience, I'm finding the >> easiest way to do WinForms is with VC2005 C++/CLI. Other than the tools >> like refactoring, what does C# buy you that C++/CLI does not have for >> building WinForms apps? >> >> I like the ability to just call my native C++ classes as usual. I had to >> write a CNativeString class to marshall C-style strings to .NET String but >> that's it. No PInvoke, no nothing, just call the native C++ class. >> >> I will eventually learn C# because the ecosystem of .NET seems to revolve >> around it, but I don't see why C++/CLI would not be a first choice for >> WinForms coming from a C++ background and with a high priority of >> interfacing to native C++ code. >> >> Thanks, >> David (MVP) > >David, > >I''ve been programming in C and C++ for almost 25 years. :Last year I >started working on my own commercial app for .NET and had to decide which >language to go with. I really didn't want to go with C# but felt I had no >choice. C++ has been bastardized to work under NET and I don't think most >developers in the real world would choose it for that environment. C# is >more natural for .NET and much easier to learn for new developers (a breeze >for C++ developers). As a result, I think that C++ is now in serious decline >in the Windows world. It will simply be much easier and far more >cost-effective to support a C# app going forward as .NET becomes the main >platform for Windows (if not already) and the number of competent C++ >developers dwindles (noting that there have always been relatively few >competent C++ developers anyway). In fact, it seems to me anyway that most >of the Windows development community is now re-tooling for .NET (or sooon >will be) and C# is clearly going to replace C++ in most shops. The >unfortunate thing is that while both languages could benefit from each other >in some ways, C++ is still a superior language IMO. I'm constantly finding >myself dealing with issues and problems in C# that I don't experience in >C++. That's another topic however but in the end I think that sticking with >C++ under Windows is a lost cause. > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 11 Feb 2007 23:37 "MrAsm" <mrasm(a)usa.com> wrote in message news:srhus25ek8a4e550943klrh4moqg6umu5b(a)4ax.com... > To me, C# RAD seems more like to Visual Basic 6 RAD. > > For example, to change the background color of a control, in C# you > simply set it into property sheet, while in MFC you should at least > have to use a custom derived class (e.g. CColorEdit, CColorStatic, > some can be found on CodeProject), then have to call proper method in > OnInitDialog(), etc. > Yes, no doubt, .NET WinForms are much higher level than MFC. It's the difference between MFC adding a syntactic sugar layer on top of raw Windows vs. doing away with raw Windows completely. If that's all you've done, it's easy to appreciate the syntactic sugar, but once you've experienced the complete abstraction of Windows constructs (never having to know what is a message pump, etc.) you wonder why you did that all these years. In addition, the advances in the IDE have all been for WinForms. The WinForms layout editor offers superior alignment during the dropping of a new control, for example. The properties exposed by controls are much better advertised in the Properties editor. I'm just starting WinForms and appreciating it more and more. Still, I think they made it too much like VB. I put a tab control into my WinForm and am amazed that all the controls for EVERY tab are put into the same WinForm! This is unheard of in MFC, where each control instance is placed into each CPropertyPage derived class. In essence, RAD makes it fast to prototype by making the form a big global variable, which seems to be hard to maintain as the program grows. Also, if there is ever a limitation or bug in .NET, the fact that it is so far removed from straight Win32 would, I believe, make it harder to figure out and fix. > But if you have not a mentor, MFC is IMHO much harder than C#. > It's definitely true, it's easy to scratch your head about how to do something in MFC. But that's what Google is for. MFC and the raw Win32 API is so well documented, if you choose your search terms wisely, you will soon have the answer. But as .NET becomes more and more in use, the same applies to that too. > Also, consider that MFC books (including the great book by Jeff > Prosise) are focused on Visual C++ 6 IDE and wizards. The Visual > Studio 2003/2005 IDE is very different from VC6 one, and - even if > that is not a big problem for a programmer who already knows MFC - I > think it is a problem for one who is learning MFC for the first time, > and has only VC6 related tutorials and books. > To learn MFC using VC2005, I highly recommend "Ivor Horton's Beginning Visual C++ 2005" (Wrox). It covers the VC2005 IDE and is a great intro to MFC. Further, there are C++/CLI chapters that make it a great intro to C++/CLI. This allows you to compare and contrast MFC with .NET. -- David (MVP)
From: David Ching on 12 Feb 2007 00:27 "Bruno van Dooren [MVP VC++]" <bruno_nos_pam_van_dooren(a)hotmail.com> wrote in message news:e5aIkghTHHA.4756(a)TK2MSFTNGP06.phx.gbl... > With 15 years of experience and an MFC background (I guess this), C++/CLI > winforms was made for you. > Yeah, it sure feels like it! I wonder why Ajay doesn't think so! :-) > But for Orcas, C# and VB.NET (barf) will get a lot of cool new features. > VC++ doesn't. > LINQ will be C# and VB only. > WPF IDE functionality will be C# and VB only. WCF and WF also. > Refactoring and powerful IDE features... C# and VB only. > > Starting from Orcas, C++/CLI is placed at a disadvantage. > Technically, you could do WPF by hand, manually creating all code and > markup scripts. > LINQ is sugar on top of .NET features, so you could emulate it using raw > .NET calls... > > But all of this is a serious productivity impairment. > Yup, Microsoft is repositioning VC++ to be a bridge between native and .NET starting with Orcas. I guess only with .NET 2.0 was C++/CLI a real first class member to create .NET programs, and it is going to fall to no-class status starting with Orcas (with no partial classes, WPF is a non-starter). Still, the OP was asking about MFC vs. WinForms, and for WinForms, C++/CLI seems to be best given his C++ background. > Lets forget about VB for a while (a long while :-)) and highlight C#. > If I can do a siginificant portion of a project in C#, my clients are > happy because it is far easier for me to hand over the project to one of > their programmers than if I had used C++/CLI, which almost noone knows. > There are tons of code examples for C#. > Intellisense and code completion works. Always. Really. > The C# IDE is crammed with productivity features. > I think once I get productive with C# I'll agree. I plan to learn .NET with C++/CLI and once I learn enough of WinForms and other .NET parts, I'll go to C#. Actually, as I use more and more prewritten C# components (it's a breeze to combine C# and C++ .NET components in the same solution now), I'll probably learn C# through osmosis. > For C++ programmers, learning C# should be a breeze. it was for me. It's > like C++ with training wheels and airbags. > Actually, I'm not finding C# all that easy. I'm bored to tears over the subtle differences like case statements not falling through, the enums, etc. C++/CLI was just the ticket for me to learn .NET concepts (such as ref and value classes) without the C# baggage getting in the way. C++/CLI makes it plain when you're using a pointer (^) and when you're using a value reference (&), and when you're calling a static member (::). C# mashes those concepts together by insisting on using '.' for everything, making it quite confusing! On top of that, C#'s clumsy PInvoke (which I'm told does nothing to enable the new Vista API's, for reasons I'm not exactly clear about) and "using" statement to insure deterministic finalization are clearly behind vs. C++/CLI. Nishant is my hero in thinking C# could be vastly improved. Your blog says there's more good C# programmers than C++ programmers, which surprised me. Perhaps due to my focus to Windows internals and hardware, I've not met many of them! :-) I think it's true in enterprise that .NET is taking over, less sure outside of big corps. Cheers, David (MVP)
From: David Ching on 12 Feb 2007 00:40
"Larry Smith" <no_spam@_nospam.com> wrote in message news:OPsaVsiTHHA.4744(a)TK2MSFTNGP02.phx.gbl... > I''ve been programming in C and C++ for almost 25 years. :Last year I > started working on my own commercial app for .NET and had to decide which > language to go with. I really didn't want to go with C# but felt I had no > choice. C++ has been bastardized to work under NET and I don't think most > developers in the real world would choose it for that environment. Hi Larry, I agree Managed C++ was bastardized, but the new C++/CLI in VC2005 is very very nice, and when it was released, it could do everything C# could do and then some... it has better optimizations for example. > C# is more natural for .NET and much easier to learn for new developers (a > breeze for C++ developers). Well, if nothing else, C++/CLI is proving to be a great crutch in focusing on .NET concepts and the library in general without worrying about C#. I mean, when we're wondering which System.Whatever.Whatever to import, do we really have to worry that an array is something like int[50] arr; and not something infinitely more natural like int arr[50]; A small point, but the .NET is a zillion small points! Something like the Y2K problem.... :-) > As a result, I think that C++ is now in serious decline in the Windows > world. It will simply be much easier and far more cost-effective to > support a C# app going forward as .NET becomes the main platform for > Windows (if not already) and the number of competent C++ developers > dwindles (noting that there have always been relatively few competent C++ > developers anyway). Yes, you're right. The day is soon coming when one cannot claim to be a Windows Developer and not know C#. That's why I'm investing now... but going through C++/CLI! :-) > In fact, it seems to me anyway that most of the Windows development > community is now re-tooling for .NET (or sooon will be) and C# is clearly > going to replace C++ in most shops. Well, I think in certain circles that is true, like in Enterprise, but not so much in ISV shops. Microsoft is making some noises in the opposite direction, in fact. See Bill Dunlap's comments at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1032378&SiteID=1 > The unfortunate thing is that while both languages could benefit from each > other in some ways, C++ is still a superior language IMO. I'm constantly > finding myself dealing with issues and problems in C# that I don't > experience in C++. That's another topic however but in the end I think > that sticking with C++ under Windows is a lost cause. Yeah, I think C# definitely is too much like Delphi and not enough like C++. But apparently C# will be the only game in town if I want to create a WPF UI. Which I think we will all have to do sooner or later. To me, that's the only compelling reason to give up C++/CLI and move to C#. Thanks, David (MVP) |