By the first article I can say that Win32 is going to be used in future.
By the first article I can say that Win32 is going to be used in future.
Lol another bash on MFC...
Using both, I can say both have their advantages and disadvantages, but besides some minor speed differences and some code bloat I don't see the evil MFC that most people here tend to espouse. MFC was never made for games, it is highly class based, and can be used to rapidly deploy certain target applications.
I suppose it is best to say use whatever you are comfortable with. As many people say, well written code in one language is better than poorly written code in something faster.
In any event, those who bash MFC, I admit its not perfect by far, but have you used it to any length?
Actually, if MFC would work in ALL compilers, I wouldn't be so offensive against it.
Well, isn't Vista's API would be the extended version of Windows Forms? Officials say that it will be the only way to access full features of the new platform. Besides, because it is part of .NET framework, it offers more speed and more security. It also offers so many new features, that otherwise people would have to code themselve. I hope this is correct.Originally Posted by Dante Shamest
My stance on 'what will take over' (raw api vs .NET/MFC/whatever) is neutral. I'd rather be a jack of all trades than master of a few.
Well whoopty-dooo. In case you didn't know, the (always has been and always will be) free Microsoft Platform SDK includes the MFC. All you have to do is get your compiler's include and library paths to point to it. Plus you get *much* more than the MFC - you get almost every official windows library available (such as ATL and DirectX.)
Chances are, you'll be able to access it using something like esoteric COM programming, but I'd much rather take the .NET route if possible.
Speed as in? Development time? Run time?Besides, because it is part of .NET framework, it offers more speed and more security.
Also, security is very situational and generalized as well these days. From things like buffer overflows, yeah, you're probably safe, but .NET can't protect you from things like logistic errors.
Last edited by Mad_guy; 06-26-2006 at 08:00 PM.
operating systems: mac os 10.6, debian 5.0, windows 7
editor: back to emacs because it's more awesomer!!
version control: git
website: http://0xff.ath.cx/~as/
These are for 64bit development only; this includes atl.
CProgramming FAQ
Caution: this person may be a carrier of the misinformation virus.
.NET is fast? In your dreams...Besides, because it is part of .NET framework, it offers more speed and more security.
Well, is it proven that .NET is lacking speed compared to the rest? I would like to see such article.
.net is similar to the java conundrum, however they did manage to speed it up much more than java. C# in particular is still run through an interpreter of sorts, though it is compiled by the MIDL ( I believe thats what they called it anyway ). So far, most things are fast in C# and .net in general. However if you plan to go lower level, you lose some speed out due to having to Marshal code and such. I am not saying .NET is a slug but what I am saying is that there is a tool for each job, and MFC happens to be a decent tool overall. It may suck for you, but it hasn't for me in the least. So I go by what I've seen, and you go by what you have seen.
I am just saying that lower level languages are better...
It may be more difficult but it's worth it.
Depends on what you mean by better. PERL is very good at handling string based things. Both PERL and PHP in my opinion are better at webpage content handling and so forth. C++ is better at speed related operations, and is very robust.
If you hate the language/construct thats fine, but let people try it for themselves. You can warn them, but hey they might find the niche you couldn't, or find something that they like that you don't.
But anyway, this is getting more offtopic then it should... bottom line, give all aspects a try if you wanna begin. Try win32 first, it is probably the easiest to wrap your mind around. Then branch out.
I don't understand, why does MFC add "C" in front of every function and structure. That is P-O-I-N-T-L-E-S-S.
And yes, I wan't to warn people - DONT USE MFC!
Many people who don't understand the real thing go over to something simple like MFC. But that doesn't help - you'll never realize how these things work. You will never become a programmer who can write clear code. That's my opionion and I repeat - DONT USER MFC!
Last edited by maxorator; 06-28-2006 at 01:58 PM.
Its to denote the fact it is a class type. As far as I know anyway, when you have hundereds of classes to deal with, it can be hard to know what is and isn't a class don't you think?
Actually, many MFC source codes I have seen have some FUNCTIONS starting with "C". Maybe MFC programmers don't understand it's for classes and think it is necessary everywhere - or are used to it and automatically add "C" in front of everything even without knowing what they are actually doing. Really, the MFC codes I've seen are so horrible, that even other MFC programmers tell they're horrible, but it still seems strange that there are so many horrible MFC programmers.
And if you have something like this "CThings::SomeFunction()", doesn't :: already mean it's inside a class?
Last edited by maxorator; 06-28-2006 at 02:04 PM.
@maxorator: That would be a static public function.
As for the C thing... If you can't remember that a class in your code is a class... well..
