tags:

views:

476

answers:

8

I have just finished my first real commercial application written in C++ / MFC.

The application consisted of agent installed on users workstations which in turn was controlled from a GUI Application on an administrators workstation. I choose C++ / MFC for these reasons.

  1. Because I didn't know C#
  2. Because I was not sure how long it would take for me to become as productive in a new lanuage
  3. Because I did not want the hassle of installing the .NET runtime on workstations some of which might be W2K.

Now I am thinking of my second application which will again consist of an agent & a GUI Application. I am happy to continue on the same track with the agent for the reasons above but the GUI application will be much more complicated then the first. The first GUI app took a very long time to develop, was torturous and looked out of date even though it was freshly made.

Should I just bite the bullet with .net c# or look into something like QT.

TIA.

A: 

C# will almost definitely make you more productive!

Patrick
+1  A: 

Delphi. Produces stand-alone Windows executables which will work fine on Win2K (best OS Microsoft ever produced - this post is being written on it). Only disadvantage is Object Pascal, but if you know C++ it's very easy to pick up - and its was designed buy the guy who designed C#. The IDE is several orders of magnitude more productive than MFC with VS.

anon
I can't resist: Win7 > Win2K. Please ignore this comment.
OregonGhost
Delphi is still a good choice, but I think it will take longer to learn than C# if coming from C++. You're right that the Delphi IDE is magnitudes better than VC++ with MFC - but it pales in comparison to VS2008SP1 with .NET and ReSharper. And he already has and knows Visual Studio. That C# was designed by the Delphi guy means that C# is his latest improvement, kind of ;)
OregonGhost
@OregonGhost But C# won't produce executables that can easily (or at all - I think .NET on Win2K is stuck at 2,0) run on Win2K.
anon
+1: C++ Builder uses the same IDE and same object framework (VCL), and is C++, for those that prefer C++ to Pascal syntax.
Binary Worrier
@Neil: You're right, but recent Delphi compilers (which is what you'd want when switching to Delphi) also don't really support NT4 or Win98. And .NET 2.0 is not bad, it has the full Windows Forms and everything BCL except for LINQ. It's ok not to have LINQ for many applications. On the other hand, our customers start not wanting to support 2K anymore (or IE6/7, for that matter). And, again, sticking to basic WinForms (or for the non-GUI part of the app) allows it to run in Mono, which is not exactly Delphi's strength, even with Lazarus/FreePascal. The VCL is unfortunately also behind the BCL.
OregonGhost
Like or not some companies are still stuck using W2K on the corporate desktop.
Canacourse
@Canacourse: It's still fine, because .NET 2.0 runs great on Windows 2K. It's the even older platforms that are a problematic choice :)
OregonGhost
"The IDE is several orders of magnitude more productive than MFC with VS." Even if we assume this is intended as hyperbole, it's *still* way over the top. More accurately, under perfect circumstances, it might, just barely, possibly, be **one** order of magnitude more productive. The only *realistic* hope of even one order of magnitude is if you work in binary (i.e. twice as productive instead of 10 times).
Jerry Coffin
@Jerry I've used Delphi extensively, MFC much less so. For me, it is definitely at least 1 order better. And hey, what's wrong with a bit of hyperbole now and then?
anon
@Neil:Certainly ignorance can reduce productivity, but with roughly equal experience, even close to a whole order of magnitude would be pretty amazing. A *little* hyperbole is fine, but even if we translate "several" to only "four", it's saying that one hour with VCL is equivalent to five years full-time with VS/MFC. Even "three" says one hour of VCL equals six months full time with MFC. I think even you'll agree that "three" is an *awfully* small "several", but even so it's nowhere close to realistic.
Jerry Coffin
+9  A: 

If you want really fast results, use .NET WinForms. Nothing beats the speed of putting together a GUI app and filling it with life, except maybe Delphi. The C# language and the .NET Base Class Library will also give you a huge productivity gain, even over the already great Qt framework. If you stick to the basic Windows Forms controls, it will even run on Mono.

WPF is even more productive once you're used to it, but getting used to it takes way more time than for Windows Forms.

OregonGhost
+1 for windows forms. +10 if I could for WPF learning curve, which if anything you've downplayed.
Binary Worrier
+1 - there's also lots of 3rd party controls which can even increase the productivity (usually at the expense of not being able to run on mono).
SnOrfus
Plus one billion. Winforms are seriously retardedly easy to get up to speed on, even not knowing c#. You can literally start churning out apps in the time it takes to set up a window with win32
Pierreten
@SnOrfus: True. If you can stick to Windows, I suggest buying one of the really great GUI toolkits like Krypton (like it (; ) or the major players. This is especially great if you have customers that value design over function. @Pierreten: Also true. WinForms is kind of old-school compared to WPF, but it is sooo easy (both to get it right and to get it wrong).
OregonGhost
A: 

on which platform will your second app run on? if it's XP and up i'll suggest C# / WinForms / GDI.

aggietech
.NET 2.0 is available for Win2K. .NET 3.5 will limit you to XP and later.
OregonGhost
Agent would have to run on W2K to Win7. GUI part only on XP or later
Canacourse
@Canacourse: Makes .NET even better suited, because the agent can be 2.0 and will run on Mono flawlessly.
OregonGhost
i think that would work still ... you can either stick with .NET 2.0 (entirely) or use .Net 2.0 for the backend agent and then .Net 3.5 for the front end.
aggietech
+2  A: 

.NET C# is a very good choice for GUI applications more generally. It's simple, to-the-point and there are vast resources on the internet.

The only thing against it I can think of, is platform compatibility, but if you're limiting yourself to C++/MFC, that shouldn't be a concern to you.

Even if you want to go platform-independent some time later, you can make a separate Gtk in .NET on Linux (Mono, the open-source .NET framework). Heck, there's even a Cocoa (Mac OS X) binding, I just don't know how mature it is. Furthermore Windows Forms is largely supported in Mono already... it really surprised me how mature it is when I was trying it out, although my primary experience with C# is on Windows.

For GUI application, you won't regret using C#. Even if you want to go cross-platform, and certainly not if you intend to only target Windows clients.

Helgi Hrafn Gunnarsson
+1 for the advice to separate GUI from functionality for a better platform independent experience.
OregonGhost
+1  A: 

I've done them all - a monkey can use C#, it's all drag and drop interfacing and public accessors. I wouldn't wish using MFC upon my worst enemy, and QT just wasn't as intuitive as C# for me. It's also really easy to make C# look nice. Difficult things like changing colors and flashing controls are trivial in C#. It also has built in styles to use. I use it professionally daily. The only time I use C++ is if I'm programming a server where every microsecond counts.

Steve H.
Note that everything you describe is Windows Forms, not C#. It's exactly the same with VB.NET, or Delphi Prism, or any other language for that matter.
OregonGhost
A: 

C# isn't that hard to adapt to, and there are literally a ton of examples online, and great books (the Head First one caught my eye as you can code a nethack clone and other fun projects). I've had to transition from C++ to C# myself, and it wasn't that rough at all (in fact it seemed like a pretty easy transition), and allowed me to rapidly prototype.

Good luck!

Terry
+1  A: 

The first question would be exactly what caused the difficulty in developing the GUI with MFC. Was it inherent to MFC, or what it because you were learning something new, and didn't really know what you were doing? To put it slightly differently, if you had to do it again today, how would the difficulty compare?

Make no mistake about it -- MFC is an old design with far more than its share of problems, shortcoming and design flaws. .NET is a lot newer, but has far more than its share of problems, shortcoming and design flaws as well.

Along with that, .NET is just plain huge. It's reasonably well organized, which helps, but it still takes quite a while to digest the sheer volume of information necessary to use it well. Likewise, while C# (for the most obvious example) is a perfectly decent language, learning to use it well isn't an overnight task either. This is probably a smaller issue though: C# doesn't really have many new concepts compared to C++. Just for example, a competent C++ programmer can easily read C# almost immediately, and while he may not use it optimally, can also write bits of C# immediately as well.

Jerry Coffin
Difficult at first because I had to figure out things I had not done before. If I had to do the GUI using MFC again it would undoubtedly be faster but I would not be keen on it.
Canacourse
@Canacourse: that's fair enough. Truthfully, with current versions of VS, development using MFC *is* rather painful (though with .NET the problems are equally bad, or a bit worse). For better or worse, I tend to compare other environments to MFC with VS 6 -- and while the compiler and MFC have improved a little since then, VS itself is *much* worse. It's recovered somewhat over the years (VS.NET was truly awful, and improvement since then have ben slow) but still falls far short of VS 6.
Jerry Coffin
@Jerry Coffin: Try out the VS2010 Beta. It's really great for C++ now. I'm actually using it to browse through the source code of a rather large application for embedded Linux, which doesn't compile on Windows. But VC++2010 understands the code better than KDevelop3, and is even in a VM much faster with all the red squiggles etc. than KDevelop4.
OregonGhost
@OregonGhost:I have the beta of VS 2010. The IDE is really *mediocre* for C++ compared to VS 6.
Jerry Coffin
@Jerry Coffin: I don't think so. I have used VC++6 in the past and wouldn't want to go back. I did several Qt projects with VC++9 and it worked fine, and a few cross-platform projects (actually Linux projects I developed in Windows) were also fine. Intellisense worked like a charm, and the compiler doesn't have all the bugs the old one had and is far more standards compliant. And, in contrast to VC++ 6, VS2010 has absolutely no problems with Intellisense for all the really crazy Boost constructs. I can't understand what would be better in VC++ 6. For .NET, VS8+9 are miles ahead anyway.
OregonGhost
@OregonGhost:Perhaps the best way for me to illustrate what I'm talking about is to ask a question or two, and see if people can show how VS 2010 matches fundamental capabilities of VS 6. Maybe I'm just missing something the rest of the world already knows...
Jerry Coffin
@Jerry Coffin: Go ahead, I'll stay tuned. I didn't experience any short-comings in VC++9 other than some missing standard headers like cstdint, but on the other hand I'm focused on .NET, and if it's C++, it's either Qt with VC++9, or semi-embedded for an ARM-Linux system...
OregonGhost
@OregonGhost:Well, I've posted the first question at: http://stackoverflow.com/questions/2211277/can-i-create-a-simple-db-browser-with-vs-2010-like-i-could-with-vs-6. No answers so far, but we'll see...
Jerry Coffin
@Jerry Coffin: Now there is an answer after the weekend, and I think it's correct. Most people today in the Windows world use .NET or Delphi for database applications, not C++. I thought you're after more substantial C++-related features, rather than things where C++ was always way behind Delphi (or even VB6, for that matter) :)
OregonGhost
@OregonGhost:Let's see: I asked "how do I do this", and you call: "you shouldn't want that" a correct answer? No insult intended, but this raises serious questions about your grasp of logic. As for your other claims, they're sort of true, but better fixes have been available for years. VS 2010 still doesn't have as good of conformance or as good of Intellisense as VS 6 with (even an ancient copy of) the Intel compiler and Visual Assist X.
Jerry Coffin
@Jerry Coffin: My logic was on another abstraction level: You're talking about serious issues with regard to VS2010's C++ support and lack of fundamental C++ functionality, and then all you want is something that is just not typical for C++ today. I meant that the answer is correct because your question does, in my opinion, not depict a serious flaw in Visual C++ 2010. Now you're basically down to "things were better in the past". If the question, today, is "How can I get RAD database functionality, quickly?", then the answer is certainly not C++, even if you're from the Borland camp...
OregonGhost
... That is kind of like saying that a modern TV doesn't have a SCART input anymore - it's true, it means that it's different from the past, but it's not a serious flaw in the modern TV because *nobody uses SCART to transmit audio and video anymore, except for old devices*. In my experience with a large Linux project, the VS2010 Intellisense and standard conformity was exactly as advertised, namely great and better than the KDevelop version we use for most of the development. It was *almost* as good as the C# Intellisense without R#.
OregonGhost
@OregonGhost:The answer is incorrect, because the proposed alternative is seriously deficient in nearly every respect. The fact is that using what it now provides produces an application that is substantially inferior to what VS 6 produced. Your argument seems to be circular:since MS doesn't support it, nobody uses it -- and since nobody uses it, there's no real for MS to support it. By that logic (using the term loosely) whatever MS does, is perfect.
Jerry Coffin
@Jerry Coffin: You misunderstood me. People use Delphi or C#/VB.NET with SWF for database applications for several years now because the languages, the libraries and the IDEs are far superior to Visual C++ 6 and allow greater productivity, so Microsoft ceased to support these scenarios and changed the Visual C++ priorities away from RAD, for which a slow compiler is a bad thing to have. Software development means choosing the right tool for the job, and just because Visual C++ 6 was fine (?) for these apps ten years ago, this doesn't mean that you should stay with it (or wait for successors).
OregonGhost