what is better for windows development? i was thinking about buying programming windows but im not sure if mfc is better or not.
Printable View
what is better for windows development? i was thinking about buying programming windows but im not sure if mfc is better or not.
There are free GUI Frameworks out there, so you don't need to buy MFC if you don't want to.
But I'll agree that a Framework is far better than pure Win32 API.
Typical good frameworks are wxWidgets or maybe Qt.
They are portable, and in some ways, possibly simplified.
You would be surprised of the capabilities of C++, that the API, which is C, cannot even begin to fathom. In essence, a good framework is ALWAYS better than the raw api. Especially for C++.
MFC is a Framework/wrapper itself and not an API, so...
MFC is not portable. It's locked to Windows and Microsoft Visual C++.
I suppose in theory it could be if someone implemented it for some other systems, but I don't know offhand of any other use for it other than Windows programming.Quote:
Originally Posted by lruc
2 questions
is mfc really not free?
and
is all the api's for windows just in windows.h?
MFC is not free (requires Standard+ version of Visual Studio, which is not free).
All APIs are located in windows.h.
It depends on your application. MFC is better for GUI, API is better for core functionality like multithreading, network connectivity, direct hardware interfaces. If you have no prior programmign experiece I recommend you start with the API, which is much easier to learn. MFC can be a bit obtuse at time.Quote:
Originally Posted by lruc
Learning the API itself is not necessary and painstaking. It's better to specialize yourself in the framework you use instead.
Otherwise you're going to end up learning both, which is usually a waste of time. Win32 API is not user friendly.
mfc is also $300 mininum and the api seems kind of lower-level code which is what i like, even if its in C
MFC is not C.
It's your choice, ultimately. You can try out several GUIs before deciding. If none of the free ones suits your fancy, then you can try MFC.
ROFLMAO, elysia, the api is simpler and more straight forward than MFC any day of the week. It's about as user friendly as you can get, I have no idea where you get off implying that MFC is in any way shape or form user friendly. Maybe you just can't understand a function description without trying to think of it as a class.Quote:
Originally Posted by Elysia
Oh really?
I've had my share of experience with both and I find MFC a thousand times simpler and easier.
Wow.
Oh really?Quote:
Originally Posted by Elysia
I've had my share of experience with both and I find the API a thousand times simpler, and faster both in development time and execution time.
Duh.
Oh really?
Maybe that's the case for YOU, but not necessarily the case for OTHERS. There's a REASON why frameworks were invented and why so many companies use MFC. I wonder why...
Duh.
Statistical distribution of intelligence and skill level in the programmer base?Quote:
Originally Posted by Elysia
Gerber is great, that doesnt mean I want it for lunch.
So now you are insulting people, too.
Yeah, C#, Java, C++, D, Python, Pearl, PHP is crap and should never have been invented.
C rules and is the only language we ever need.
All else is superfluous and anyone who can't use it or do it well are morons that needs to be shot.
And because C rules we don't need crap like MFC, Qt, wxWidgets. We only need the raw API because it rulez and everything else sucks.
Wow, I can see you completely missed the point. Didn't I just get done saying that MFC is better than the API at GUI? So now you imply that im some sort of zealous language bigot hell bent on eradicating coding in anything but 1's and 0's using a car battery and a 27C16.
No, the point is that I find MFC better at everything.
Regardless if it's GUI or not.
Even if it's a wrapper, it's encapsulated in classes which makes everything better.
C is yesterday. C++ is today.
Now who is being the bigot?Quote:
Originally Posted by Elysia
[sarcasm]
C++ roolz, C is crap, classes make everything better, for loops suck, use the new CLoop->For() method instead.
[/sarcasm]
If you want to compare egos, go ahead. I will stop bickering about this now, since it will neither of us any good.
No I wont even go near that can of worms. You clearly win in the ego contest. I merely state the fact that I am smarter than 98% of the human race, you think you are a god.Quote:
Originally Posted by Elysia
If you say so.
I would still, however, say that frameworks are better than the API, because the API is a mess.
A framework can correct flaws and create a more pleasing environment for many.
I do NOT think you should diss MFC to only those incapable of using the Windows API.
Well that is where we disagree. I believe that those capable of getting closer to the metal should do so as ultimately they will find it a much more rewarding and productive experience.
Quote:
ROFLMAO, elysia, the api is simpler and more straight forward than MFC any day of the week. It's about as user friendly as you can get, I have no idea where you get off implying that MFC is in any way shape or form user friendly.
Quote:
Statistical distribution of intelligence and skill level in the programmer base?
Gerber is great, that doesnt mean I want it for lunch.
Time and time again in threads with Elysia you attempt to prove your point by personal attacks. This is very tiresome and an extremely immature form of debate. If you and Elysia have issues may I suggest you sort them out outside of otherwise peaceful threads.Quote:
No I wont even go near that can of worms. You clearly win in the ego contest. I merely state the fact that I am smarter than 98% of the human race, you think you are a god.
And now to the original question:
My opinion is that MFC is indeed simpler than pure Win32 API. If that makes me a crappy C++ programmer then so be it...I'm a crappy C++ programmer.
Any opinion here is going to be just that. In order to find out for yourself which is easier you will have to gain some experience with both.
For me, by chance, I started Windows programming with MFC first. At that time, I was a simple *user* of the framework. Doing something that I'd never done before required hitting the reference material and hopefully finding complete samples that demonstrated what I was looking for.
Then I got Petzold, and started learning the overall concepts in the Win32 API that MFC "took care of" for me. Once I started understanding how the framework itself worked on top of the Win32 API, I no longer felt like a simple user. Doing something new no longer required samples; just reading the MSDN pages on per-MFC object basis was enough to get going.
A lot of MFC isn't just a simple wrapper of the raw API - and those parts of MFC I ended up learning last - by virtual of buying and reading an MFC book :) (document-view arch. comes to mind). And there are other parts of the framework that I've never touched.
Based on my experience, I used to advocate learning the raw API first, so that you can understand and appreciate what MFC is "taking care of for you" - which would hopefully make for a faster tract towards mastering the framework.
In the end, I think that if you want to *master* MFC (at least the portions of the framework that wrap raw API's), then the raw API should be learned at some point.
However, I no longer advocate learning one before the other. I think that really depends on your personal short-term and/or long-term goals.
gg
I learnt WIN32 then MFC.
I still use both, in the most apps I write.
Somethings can't be done in WIN32 and many things are quicker with MFC.
As Codeplug said, depends where you want to take your programming.
Hobbist would probably be better with MFC and somer WIN32.
Career, I would recommend a much deeper understanding of WIN32, it will force you to write better code (and allow you to bypass the limitations of MFC as required).
Err... may I suggest neither MFC or Win32 API?
I'm honestly unsure where these two will lead and if at this point it pays to learn them. Probably Win32 API will be around for quiet a while still, but definitely I wouldn't put much effort in learning MFC at this point since Microsoft clearly wants to get rid of it as soon as it can.
The .Net Framework is a viable and more intelligent alternative to MFC. Viable because it apparently does a better job at streamlining code development than MFC ever did, and intelligent because this is the route Microsoft wants you to take. My gripe with .Net derives solely from the fact I strongly believe this thing should have been built with C++ in addition to C# (if they really had to create C#, in the first place. But that's an altogether different discussion).
The other option, in case you want to stick to C++ programming, is to learn one of the 3d party libraries available to you. These are extremely good up-to-date libraries that simplify your windows code considerably when compared to MFC (and provide a lot more features). They are also much easier to learn and more more intuitive to use. But more important, they are portable across different OSes. WxWidgets and Qt are the most used ones. I prefer wxWidgets and have been playing around with Qt too.
WxWidgets seems to me more mature and with more features. But started out in a time when the STL was in its infancy, for which reason it doesn't provide native support for STL types. It doesn't mean you can't use them. Just that it will be a little more awkward to do so, since wxWidgets uses instead its own STL-like objects and you will be constantly casting between types. It's my pet-peeve with wxWidgets, despite being my favorite library. I don't think there's anything you can't do in windows with it.
Qt is a much more... modern(?)... approach to windows development. It fully supports STL, thank goodness, it outperforms (in my opinion and after only preliminary observations) wxWidgets in several important areas like grid and list controls, screen rendering and multi-threading. Its licensing system however demands money if you want anything above some basic functionality. It also comes behind in number of features when compared to wxWidgets.
...
Personally I would either go with C# or one of those two libraries. After you build some confidence, I only then suggest you learn Win32 API. For one you will be then more motivated to do so. But most importantly, you will also be better prepared to understand some of the gritty details. Not that you can't learn the API without all that baggage behind you, just that it will be easier and probably more fun.
Finally... a disclaimer:
I'm not really saying MFC is not an option - I think a large chunk of windows programming is still done in MFC. On the other hand skills in MFC should still be a priority if you are interested in learning windows programming with a career in mind. In that case, definitely forget about 3rd party libraries for now... unfortunately, I say. And go all the way C# on one hand and MFC on the other, with Win32 API as soon as you feel more or less comfortable.
But I do argue the future of MFC, though. And if you are not immediately pressed, don't go that route.
Portability is a kid concept.Quote:
Originally Posted by MacGyver
99.99% of customers use Windows in Front-End applications.
They don't care of portability.
This forum cares about portability. And it's not a kid concept.
But I would like to say steer away from C# and any dotNet, because IMO, it's a mistake. Plus it will probably not be very portable, and still isn't very portable.
They are slow and bloated. The borderline between low level programming and dotNet is, well, C++. With the right tools and libraries, we can maintain performance, efficiency, and still write good applications.
Of course, if you're considering real-world application, you may be forced to go down the path of dotNet, because companies don't really care if it's slow or bloated as long as it takes less time to write an application.
i was never a fan of .net. .net is very slow compared to c++ and i dont think .net will ever replace c++, even in companies.
i actually do care about portability. the only problem is i dont like 3rd party libraries that much. the day the standard libraries get grahics, sound, and networking libraries i will become a portable programmer.
So until then you won't use graphics, sound, or networking? :rolleyes:
Oh well... I don't think this "C# is slow" mantra will ever end. It's been discussed so many times of these forums and it hasn't yet.Quote:
Originally Posted by lruc
Just do yourself a favor... don't... buy... the... C#... is... slow... argument. You won't regret it. If that's your problem with C#, then you clearly need to study it better.
uh? You just don't like them because you don't know them, or you don't like them for a specific reason you are not sharing with us. I'm most curious as to what the collective of 3rd party libraries has that makes you not liking it...Quote:
Originally Posted by lruc
Since the answer is probably going to frustrate me, I suggest instead your reevaluate your position and consider that the strength of C++ lies exactly on its 3rd party libraries. The language itself, plus Standard Library and STL is pretty much dull and boring... unless you are a 3rd party library developer. Which obviously you are not.
c# being slow is something i have just heard many times and you might be right, but i really dont know. also, its not so much that i dont like 3rd party libraries so much as i prefer the api's instead. was that frustrating???
The slowness of C# compiled code isnt a property of the language itself, but a consequence of its implimentation. The first C/C++ compilers werent all that fast compared to assembly, bu tthye improve over time. Im sure of C# recieves a lot of attention it will improve over time as well. Its really more of a transitional language though, meant to help stear VB users towards C/C++ without the steep learnign curve of a comlete switch. In microsofts own words C/C++ are the language of choice for performance and raw computing power. They also stopped supporting FoxPro so both of the foxpro users are looking for a replacement language.
C# is just Microsoft's own attempt to monopolize the programming market, if you ask me.
They don't own C/C++, but they can have a lot of say in C#.
I doubt C# will get faster due to its nature. It's interpreted and compiled. Maybe you could say dynamically recompiled.
But the fact is that it is not native code and therefore will always run slower than C/C++, regardless of what Microsoft says.
Well, regardless what you good people say, I say C# is not slower than C++ for the type of applications it targets. And when it is, it's almost always negligible.
For all that matters, my beloved C++/wxWidgets is at least one magnitude slower than C# on most windows related tasks. And yet... you guessed it... nobody seems to care. I don't hear a ruckus about it, do any of you? (and still is a quiet promising way of programming for Windows... or no one uses CodeBlocks anymore... because it's slow?)
It becomes an issue if the 0.1 seconds it takes to load a 10,000 item list control after you click a button is unacceptable and what you want is 0.08 seconds. But then... well, lets just say the bottleneck is almost always on the code and rarely on the language.
If you want to squeeze every bit of performance of your GUI application, the best option - and the one that brings sure results - is changing programmers, not programming languages.
This obviously is incorrect since Microsoft just updated the entire MFC framework as of MSVS 2008. Microsoft is going to publish whatever the devs will buy and they found a lot of devs wanted an update to MFC so that's exactly what they gave them.Quote:
...I wouldn't put much effort in learning MFC at this point since Microsoft clearly wants to get rid of it as soon as it can.
But it is true that even Microsoft clearly states that they have no intention of replacing C/C++ via C# or any other language out there. They recommend C/C++ over all others if you need raw power. Fact is most applications do not and C# will suffice.
In my own experience C# apps do run a bit slower than MFC apps. Whether this is because I suck at C# or not is definitely up for debate. Overall I find it takes more time for common dialogs to come up and for common controls to do their 'thing' whatever that may be. It feels as if .NET takes a very long time to load 'something' when you are using the default controls and dialogs but I've never discovered what it is or read anything as to why this may occur. Perhaps this is more of a problem with .NET than C# since C# seems to do quite well for most in XNA. So perhaps the more correct answer is that .NET is slower than the CRT which I believe we all would agree on.
C# is a very nice language though and .NET supports just about anything you would want to do and more. I honestly cannot make a recommendation between C# and MFC C++ apps. For me the final decision is how easily will the tool interface with existing tools? Another big question is what are the current crop of tools written in and if I change that do I unnecessarily increase the maintenance task? Most of these decisions are made far above my pay grade but that is some of the thought process they have told us they use to determine which language to use for tools. Is it easier to teach new devs MFC or C#? If most the tools are in C# using MFC may not be a wise choice and vice versa. For now most of our GUI tools are written in C#. I will say this has made it difficult at times to interface with existing code for testing and so forth since managed and unmanaged code do not play well together. If somehow the interop between C# and C++ could be eased a bit I think it would be even more widely used. For now it usually comes down to making a COM component that acts as a wrapper or writing a C style wrapper that wraps access to the C++ class. The wrapper then can be called from C# since C calls are not using this call and the wrapper then calls the C++ functions.
Your choice of framework / API shoud depend on where you want to go with programming.
The software houses I have worked for have only used WIN32 and MFC. (for C/C++ GUIs)
None used any third party API commercially.
You may dislike MFC, but it is not going anywhere quickly. We are simply not porting to .NET (nor to Vista).
If you plan a programming career, experience with the frameworks / APIs used commercially is more important than which one YOU prefer.
Didn't know about this. Just took a quick look. It however seems to me mostly a cosmetic getting up-to-date effort, Bubba. Mostly new controls. Although, the new shell management classes and TR1 support seem no doubt a great addition. They also say they will keep improving it...Quote:
Originally Posted by Bubba
Well glad I'm wrong on this one. It's been my reasoning that one of Microsoft wishes behind .Net is exactly to cut down on C++ development on windows on account of all security issues that plague the operating system. MFC would, on this case, be a priority target. The pushing of C#, no framework support for C++, an outdated MFC, a .Net based OS, all contributed to this general feeling I had; basically that Microsoft is winking everyone into .net development and to drop C++/MFC/Win32.
I'm still somewhat unsure. I wonder how much of that upgrade wasn't the result of pressure from major customers and public in general... and, at the same time, Microsoft realization C# didn't really replace C++ as much as they wished.
C/C++ are MS's bread and butter, they will not 'deprecate' it in our lifetime. MFC and .NET are fine for most applications, but new and innovative and particularly science and engineering related development requires more than just out of the box classes. This is one of the reasons I was appalled to find no support for inline assembly in x64, since the very market that is most likely to use x64 is the same market that is most likely to use inline assembly (engineers).
You're not alone in that you are appalled to see no inline asm support in x86.
It has been one of the reasons I've been reluctant to embrace x64. Although, nowadays, I'm less likely to rely on asm. Still, it's a very big shortcoming of ms, if you ask me.