MFC/C++ vs .NET
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Steve_pqr wrote:
Is there any advantage for me at all in going .NET?
Yep!, if you're doing GUI work productivity will be fanfold, I used to use MFC/C++/ATL, no longer, get your head into C# and you'll never look back.
We made the buttons on the screen look so good you'll want to lick them. Steve Jobs
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
This is an interesting question for me too steve. Im in a very similar situation to you steve (in terms of the type of work I do), Im still writing in C++/MFC Visual Stidio Version 6, and I still havent been able to justify in my own mind, the change to .NET. Id be very interested to hear other opinions... Anybody? Cheers
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Steve_pqr wrote:
What other things would anyone recommend I do to improve the way I work
Stop copy and pasting and create a code base of re-usable code. How many times have you had to go through all your utilities because you found a bug in some code you've c&p'd among a dozen apps?
Steve_pqr wrote:
Is there any advantage for me at all in going .NET?
Honestly, no. I'm being blunt here, but it seems like you've got a few other things to learn first. That isn't intended to be derogatory at all. MFC and the way you're writing utilities is a fine approach (except think about code libraries). Rather than delving into .NET, I'd recommend working on improving your understanding of OOP and programming practices in general. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
I use VC++6 for existing projects because changing over to another compiler is a non-starter. For new programs I use VC++6 if they interact closely with existing programs, for ease of code reuse. C# is strictly for new projects that are totally independent.
-
Steve_pqr wrote:
What other things would anyone recommend I do to improve the way I work
Stop copy and pasting and create a code base of re-usable code. How many times have you had to go through all your utilities because you found a bug in some code you've c&p'd among a dozen apps?
Steve_pqr wrote:
Is there any advantage for me at all in going .NET?
Honestly, no. I'm being blunt here, but it seems like you've got a few other things to learn first. That isn't intended to be derogatory at all. MFC and the way you're writing utilities is a fine approach (except think about code libraries). Rather than delving into .NET, I'd recommend working on improving your understanding of OOP and programming practices in general. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithYes I know I have more to learn - problem is I'm an engineer not a programmer and secondly I'm trying to do development in what is essentially a production environment - time to sit and read and try stuff out I just don't have! On the subject of code libraries how would you suggest I go about this? Just have a directory full of 'well commented' code snippets/classes/projects or would there be a more structured way to do things, how do other programmers handle their reuseable code? Steve
-
Yes I know I have more to learn - problem is I'm an engineer not a programmer and secondly I'm trying to do development in what is essentially a production environment - time to sit and read and try stuff out I just don't have! On the subject of code libraries how would you suggest I go about this? Just have a directory full of 'well commented' code snippets/classes/projects or would there be a more structured way to do things, how do other programmers handle their reuseable code? Steve
Steve_pqr wrote:
On the subject of code libraries how would you suggest I go about this? Just have a directory full of 'well commented' code snippets/classes/projects or would there be a more structured way to do things, how do other programmers handle their reuseable code?
It's a double edged sword, because re-usable is like the Holy Grail. In my case, I start with a "public" and a "private" folder--the public folder contains code that I'm donating to the community. Private is re-usable stuff that's proprietary. Within that, I've found that separating code by functional groups is pretty good. So I have subfolders for string stuff, TCP, data management, xml, threading, streams, etc. Even though I'm a one-man shop, I put all the code under version control as well. I'd recommend working out how you'd like to organize the code into library and projects, where re-usable stuff goes into library, and have subfolders in the library that organize the code further. As to re-use, code organization is the first step. However, making code re-usable takes work. Questions that need to be asked and answered: what fields/properties/methods are public, protected, or private? which methods need to be virtual because they may be overriden? do I need to implement some sort of "value changed" event mechanism? which classes are abstract, so they can't be directly instantiated? since you're in C++, are all your destructors marked virtual? which classes are singletons that might need static factory methods? And definitely, well commented! :-D Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Yes I know I have more to learn - problem is I'm an engineer not a programmer and secondly I'm trying to do development in what is essentially a production environment - time to sit and read and try stuff out I just don't have! On the subject of code libraries how would you suggest I go about this? Just have a directory full of 'well commented' code snippets/classes/projects or would there be a more structured way to do things, how do other programmers handle their reuseable code? Steve
You can create DLL's that all your components can use. I always have an "update" tool with my applications that automatically updates the DLL's if i need to correct something. This is a very easy approach.
Brad Australian "Keyboard? Ha! I throw magnets over the RAM chips!" - peterchen
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Contrary to what .NET evangelists are saying, .NET stuff isn't for all situations and scenarios. I'm writing code for machines where the overhead of .NET is simply just not an option. If I were you, I'd take a look at what I'm doing, and what I will be doing in the near future. If you're going to write time critical applications (think soft realtime systems, or systems with low hardware specs), then fiddling with .NET for anything than hobby activities, is just a waste of time.
-- Verletzen zerfetzen zersetzen zerstören Doch es darf nicht mir gehören Ich muss zerstören
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Steve_pqr wrote:
Is there any advantage for me at all in going .NET?
Couldn't say for sure, but if you decide to go there, be very cautious when picking the GUI framework. Winforms are not only ugly, but also practically deprecated. There is the new framework, WPF, but the jury is still out with this one. Why don't you look at some nice C++ GUI library, like VCF[^]?
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
For stand-alone apps outside a corporate environment, .NET simply isn't there yet. Even in corporate environments, if you are doing more than basic GUI code, .NET will drive you up a wall.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Contrary to what .NET evangelists are saying, .NET stuff isn't for all situations and scenarios. I'm writing code for machines where the overhead of .NET is simply just not an option. If I were you, I'd take a look at what I'm doing, and what I will be doing in the near future. If you're going to write time critical applications (think soft realtime systems, or systems with low hardware specs), then fiddling with .NET for anything than hobby activities, is just a waste of time.
-- Verletzen zerfetzen zersetzen zerstören Doch es darf nicht mir gehören Ich muss zerstören
Joergen Sigvardsson wrote:
Contrary to what .NET evangelists are saying, .NET stuff isn't for all situations and scenarios.
You're tarring with too wide a brush. I've spent my entire professional career doing .NET development, but if someone were to come to me with requirements for an app that was either hard realtime, highly computationally intensive, or very large (ie office type app), I'd still point them to C++.
-- Rules of thumb should not be taken for the whole hand.
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Many people would say that if you are creating GUI based programs, then .NET is the way to go. We still use MFC for some very good reasons: 1) For what we do, we can buy a set of GUI widgets for the whole company for 6K and get more functionality from MFC than NET. 2) Too many people fall into the trap that being able to create GUI fast is a good thing. The vast majority of most significant software programs is what is behind the GUI and not the GUI itself. We have created better software and GUI using MFC than we ever did with RAD tools. We take the creation of the software much more seriously.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Steve_pqr wrote:
Is there any advantage for me at all in going .NET?
It doesn't sound like it (for you).
Steve_pqr wrote:
What is the point of .NET?
Do you need to build, deploy, or manage Web services? http://www.microsoft.com/net/basics_faq.mspx[^]
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
For stand-alone apps outside a corporate environment, .NET simply isn't there yet. Even in corporate environments, if you are doing more than basic GUI code, .NET will drive you up a wall.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
Even in corporate environments, if you are doing more than basic GUI code, .NET will drive you up a wall.
How so? I don't find this experience at all. .NET is alot easier to work with than COM/ATL. Also easier than MFC. Hell, the threading, delegate/event, tcp/ip frameworks are all alot easier, especially with Async support out of the box, and ADO is a lot cleaner than what we had with OLE-DB. Bah! Which wall is this that you speak of?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
Steve_pqr wrote:
s there any advantage for me at all in going .NET?
No, but you should at least get VS2005 so that you have the latest tools.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Joe Woodbury wrote:
Even in corporate environments, if you are doing more than basic GUI code, .NET will drive you up a wall.
How so? I don't find this experience at all. .NET is alot easier to work with than COM/ATL. Also easier than MFC. Hell, the threading, delegate/event, tcp/ip frameworks are all alot easier, especially with Async support out of the box, and ADO is a lot cleaner than what we had with OLE-DB. Bah! Which wall is this that you speak of?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
Chris S Kaiser wrote:
Hell, the threading, delegate/event, tcp/ip frameworks are all alot easier, especially with Async support out of the box
I differ, but then I'm an MFC/Win32 expert (not to brag, I just don't find any of those things difficult and didn't find .NET made them easier. I actually found threading in .NET more difficult for non-trivial code [though version 2.0 did some improvement, but not nearly enough.]) But, I was clearly referring to GUI code. .NET is still half-baked when it comes to writing UIs for client applications. I've yet to write anything non-trivial where I didn't have to use P/Invoke. Worse, many times I'm using P/Invoke for things that are provided by Win32 and SHOULD have been present in .NET but were either overlooked or some pea-brain figured nobody needed it.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
I'm a self taught programmer brought up on BASIC, FORTRAN then C and onto C++. I tend to write standalone apps - usually utilities of one sort or another aimed at mathematicians and engineers. My approach is nearly always the same - open MSVC, select New App, MFC, dialog based and write away. If I need code I wrote before I cut and paste or copy the existing files into the new project. It works fine for me! Is there any advantage for me at all in going .NET? What is the point of .NET? What other things would anyone recommend I do to improve the way I work bearing in mind the words 'old dogs and new tricks' and the fact that I only recently learned that inheritance was not something you got off your granparents when they died...:) Steve
I remember back in the 90s when the conversation at every shop I landed in was a debate over whether they should code in Visual Basic or MFC / C++. "We can code it so much quicker in VB" was the battle cry. My observations as a mercenary working in a host of different shops was that the first 80% happened like lighting. The last 20% frequently faltered or even hit a "this can't be done" wall, especially in earlier versions of VB. In less experienced hands, MFC / C++ can take significantly longer on that first 80%. However, there is no wall. Want to make an API call? You can make it. Want to execute inline assembler? No problemo. As for myself, I like a language that doesn't say no. What's that you say, you weren't talking about Visual Basic? Of course you were. Anyone who's not in massive denial can see that the .NET platform, as well as the Visual Studio IDE, is the obvious illegitimate offspring that one would expect from Visual Basic having an illicit affair with a web browser. That being said... Although I think a web browser is no place for serious application code to find itself and I don't like languages telling me no, I nonetheless think for quick and trivial dialog based apps that Winforms / C# (or even VB.NET) might prove very productive. Besides, it's clear that MFC / C++ guys are fast becoming the red headed stepchildren of the developer community in the eyes of Microsoft. This is where they want to herd us, and that alone is a good reason to become familiar with the turf. Just don't throw away your copy of VC++ 6.0. ;)
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
Chris S Kaiser wrote:
Hell, the threading, delegate/event, tcp/ip frameworks are all alot easier, especially with Async support out of the box
I differ, but then I'm an MFC/Win32 expert (not to brag, I just don't find any of those things difficult and didn't find .NET made them easier. I actually found threading in .NET more difficult for non-trivial code [though version 2.0 did some improvement, but not nearly enough.]) But, I was clearly referring to GUI code. .NET is still half-baked when it comes to writing UIs for client applications. I've yet to write anything non-trivial where I didn't have to use P/Invoke. Worse, many times I'm using P/Invoke for things that are provided by Win32 and SHOULD have been present in .NET but were either overlooked or some pea-brain figured nobody needed it.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I differ, but then I'm an MFC/Win32 expert (not to brag, I just don't find any of those things difficult and didn't find .NET made them easier.
I started with win32 and MFC and have written my own framework to handle win32 complete with message crackers and owner drawn controls. I found .NET much easier to work with. And I'm not just talking about C#, but the framework itself.
Joe Woodbury wrote:
I actually found threading in .NET more difficult for non-trivial code
How so? To map members they have to be static, or pass in a void pointer to 'this'. Thread.Start is just as easy as beginthreadex. lock and Monitors are a bit easier to control race conditions. lock itself is much easier than TryEnterCriticalSection. I don't see how .NET is more difficult. I'm not against the old way, I just find this new one easier to code.
Joe Woodbury wrote:
But, I was clearly referring to GUI code.
Well, it wasn't clear to me. Work with Tab Pages in win32. And tell me its easier than in .NET. I dare ya.. Or I should say Property Sheets and Property pages that require a kludge just to encapsulate. Requiring Post/Send messages just to move data around. The tab control in .NET along with just adding controls to the control list of the tabs is so much cleaner and easier to work with. In fact, in the GUI arena is where it really shines for ease of use.
Joe Woodbury wrote:
I've yet to write anything non-trivial where I didn't have to use P/Invoke.
I'm writing commercial applications that aren't trivial, and I've yet to need to use P/Invoke.
Joe Woodbury wrote:
Worse, many times I'm using P/Invoke for things that are provided by Win32 and SHOULD have been present in .NET but were either overlooked or some pea-brain figured nobody needed it.
Like what?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
Joe Woodbury wrote:
I differ, but then I'm an MFC/Win32 expert (not to brag, I just don't find any of those things difficult and didn't find .NET made them easier.
I started with win32 and MFC and have written my own framework to handle win32 complete with message crackers and owner drawn controls. I found .NET much easier to work with. And I'm not just talking about C#, but the framework itself.
Joe Woodbury wrote:
I actually found threading in .NET more difficult for non-trivial code
How so? To map members they have to be static, or pass in a void pointer to 'this'. Thread.Start is just as easy as beginthreadex. lock and Monitors are a bit easier to control race conditions. lock itself is much easier than TryEnterCriticalSection. I don't see how .NET is more difficult. I'm not against the old way, I just find this new one easier to code.
Joe Woodbury wrote:
But, I was clearly referring to GUI code.
Well, it wasn't clear to me. Work with Tab Pages in win32. And tell me its easier than in .NET. I dare ya.. Or I should say Property Sheets and Property pages that require a kludge just to encapsulate. Requiring Post/Send messages just to move data around. The tab control in .NET along with just adding controls to the control list of the tabs is so much cleaner and easier to work with. In fact, in the GUI arena is where it really shines for ease of use.
Joe Woodbury wrote:
I've yet to write anything non-trivial where I didn't have to use P/Invoke.
I'm writing commercial applications that aren't trivial, and I've yet to need to use P/Invoke.
Joe Woodbury wrote:
Worse, many times I'm using P/Invoke for things that are provided by Win32 and SHOULD have been present in .NET but were either overlooked or some pea-brain figured nobody needed it.
Like what?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
Chris S Kaiser wrote:
I don't see how .NET is more difficult.
.NET 1.1 was lacking several synchronization objects. .NET improved a bit in that regard but still has no direct support for certain things, like shared memory.
Chris S Kaiser wrote:
Joe Woodbury wrote: But, I was clearly referring to GUI code. Well, it wasn't clear to me.
lol, I stated "if you are doing more than basic GUI code". I did NOT say there weren't things that were easier in .NET, there are. But there are also many things that are harder. The Tree View for example, is lacking some obvious methods. Property Sheets and Pages aren't difficult in MFC at all. Neither are tab controls. I've never had to do a kludge except when doing something very unusual (which required a kludge in the .NET version as well.) One example is .NET does not expose the equivilant of the ShellBrowseForFolder dialog and several Shell functions. The Tree View and List View are both missing some minor methods that are useful in extending both. (I have working code for the BrowseForFolder and an extension to Tree View, but haven't written an article since some of the code isn't mine and I have no idea where I got it.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
