From: Larry Smith on
> 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
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
"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
"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
"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)