MFC/C++ vs .NET
-
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
-
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
Joe Woodbury wrote:
lol, I stated "if you are doing more than basic GUI code".
I misunderstood that to mean non-GUI. My bad.
Joe Woodbury wrote:
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.)
Heh, when attending the Guerrilla.NET course at DevelopMentor in 2001 it was the ease of using the tab control and the threading mechanisms that caused me excitement. I was one of the dissappointed in losing some of what C++ gives us, such as scope relation to the destructor. But the gui stuff I liked. Granted though, the ListView is lacking as well, no clear way to associate data. The tree view though didn't present a problem to me, but I don't use all of its features. I haven't had to shell out in this current job. But property pages and sheets just frustrated me in both win32 and MFC. Dunno, guess its a matter of opinion.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
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[^]?
Unfortunatly WPF is a little too fresh for most of us. Plus you need to download two frameworks instead of one, which is a big disadvantage too. I just finished up work on a Winforms application that uses the Composite Application Block and I totally disagree with you that winforms is deprecated. It's a rocksolid framework that has plenty of flexibility and at the moment this is the only GUI product for .NET that is beyond the post-beta bugs period. Although WPF is interesting, it's also a really new framework that isn't that well documented, you will need a book and a lot more samples then there are at the moment.
WM. What about weapons of mass-construction? "You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
-
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
-
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:
if you are doing more than basic GUI code, .NET will drive you up a wall
Please enlighten me, I've having no problems with a 100+ user accountancy/manufacturing system?
We made the buttons on the screen look so good you'll want to lick them. Steve Jobs
-
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.
Tim Smith wrote:
Too many people fall into the trap that being able to create GUI fast is a good thing
Ah I agree, it takes years of practice, I find copying current GUI designs, I'm no GUI expert but I find looking around at Microsofts, Adobes GUIS and gleaning the best of worlds.
We made the buttons on the screen look so good you'll want to lick them. Steve Jobs
