.NET or C++/MFC?
-
I just got started writing Windows-Apps in C++ and C#. The .Net concept seems to me much easier, exspecially because it has a "real & full" object oriented structure and not that confusing ResourceFile-concept of MFC. If I use a button, I can see how it is instantiated, properties are set etc. As a bottom up C++ Learner it is somehow confusing to me, to describe Buttons etc. in Resourcefiles instead of coding them into real c++ sourcecode. The big disadvantage I see at the moment is, that even if you want to distribute a small Tool, you force the user to install the whole .NET framework. But maybe in some months, nearly every Windows-System will have this Framework already installed. My Question is now: As a Newbie, should I better continue writing in C# or C++/MFC? And in this context, is it possible to use some more "advanced" features in .Net like playing sounds, use external dlls (lame, zip etc.) or accessing the serial port for example? Thanx for your opinions Mario
-
I just got started writing Windows-Apps in C++ and C#. The .Net concept seems to me much easier, exspecially because it has a "real & full" object oriented structure and not that confusing ResourceFile-concept of MFC. If I use a button, I can see how it is instantiated, properties are set etc. As a bottom up C++ Learner it is somehow confusing to me, to describe Buttons etc. in Resourcefiles instead of coding them into real c++ sourcecode. The big disadvantage I see at the moment is, that even if you want to distribute a small Tool, you force the user to install the whole .NET framework. But maybe in some months, nearly every Windows-System will have this Framework already installed. My Question is now: As a Newbie, should I better continue writing in C# or C++/MFC? And in this context, is it possible to use some more "advanced" features in .Net like playing sounds, use external dlls (lame, zip etc.) or accessing the serial port for example? Thanx for your opinions Mario
You should learn both. .NET makes things easy, but C++ is a more powerful tool. You can't know too much, so don't feel you need any limits, just learn anything you can. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?! - Jon Hulatt, 22/3/2002
-
You should learn both. .NET makes things easy, but C++ is a more powerful tool. You can't know too much, so don't feel you need any limits, just learn anything you can. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?! - Jon Hulatt, 22/3/2002
OK, thats absolutely right. Now here's the big but: Time. I think I've to decide which language to use (which Package I buy for my own). Maybe I continue with C++/MFC, because as my projects may get bigger, I don't want to hit on any limits and then rewrite the whole stuff in another language/environment.
-
I just got started writing Windows-Apps in C++ and C#. The .Net concept seems to me much easier, exspecially because it has a "real & full" object oriented structure and not that confusing ResourceFile-concept of MFC. If I use a button, I can see how it is instantiated, properties are set etc. As a bottom up C++ Learner it is somehow confusing to me, to describe Buttons etc. in Resourcefiles instead of coding them into real c++ sourcecode. The big disadvantage I see at the moment is, that even if you want to distribute a small Tool, you force the user to install the whole .NET framework. But maybe in some months, nearly every Windows-System will have this Framework already installed. My Question is now: As a Newbie, should I better continue writing in C# or C++/MFC? And in this context, is it possible to use some more "advanced" features in .Net like playing sounds, use external dlls (lame, zip etc.) or accessing the serial port for example? Thanx for your opinions Mario
If there is a Win32 API you want to call, you can call it in your .NET application. With that said you can do just about anything with .NET that you can with C/C++ the question now becomes, should you? You have to remember that a .NET app will run about 80-90% slower than the C/C++ app that does the same thing. If your program can tolerate that then there isn't any reason not to use it unless you need to target Win95. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
-
If there is a Win32 API you want to call, you can call it in your .NET application. With that said you can do just about anything with .NET that you can with C/C++ the question now becomes, should you? You have to remember that a .NET app will run about 80-90% slower than the C/C++ app that does the same thing. If your program can tolerate that then there isn't any reason not to use it unless you need to target Win95. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
Good hint- Thanx. Maybe I'll call ngen on all my assemblies first to speed up the whole thing. On todays PCs a "normal" App (no big calculations etc.) should work, I think. And as I learned how to import extern dlls today - there doesn't seem to be any big restrictions left. Hopefully the C#-community will get as big as the MFC-Scene is today - that helps a lot on solving problems. Mario
-
If there is a Win32 API you want to call, you can call it in your .NET application. With that said you can do just about anything with .NET that you can with C/C++ the question now becomes, should you? You have to remember that a .NET app will run about 80-90% slower than the C/C++ app that does the same thing. If your program can tolerate that then there isn't any reason not to use it unless you need to target Win95. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
James T. Johnson wrote: You have to remember that a .NET app will run about 80-90% slower than the C/C++ app that does the same thing I think this is an exaggeration. Where did you get that information ? There are so many different types of program.. that statement sounds unreal. No offense :) Andres Manggini. Buenos Aires - Argentina.
-
James T. Johnson wrote: You have to remember that a .NET app will run about 80-90% slower than the C/C++ app that does the same thing I think this is an exaggeration. Where did you get that information ? There are so many different types of program.. that statement sounds unreal. No offense :) Andres Manggini. Buenos Aires - Argentina.
I'm pretty sure the figure came from the DOTNET mailing list from either someone at MS or John Lam who did a lot of different tests regarding IL -> x86 generation; I'm leaning towards it being John because that would have been the context to get the figure out. If thats the case the 80-90% figure is comparing the x86 code that the JIT produces versus the C++ x86 code that is produced. James Simplicity Rules!