Slashdot Mirror
Porting From MFC To GTK
crazney writes "Linux.com has an article up by Ryan Gorden of Loki on porting from Windows to Linux, in particular the troubles faced with Microsofts MFC API and the extensions implemented by Microsofts Visual C++ on the C++ language." Talks about porting, the gaming industry, and gives suggestions for portability from someone who should know.
Legality aside, don't forget your end users; not only are win32 wrappers considered to be "cheating" by the Linux community, no one wants to run a native Linux application that looks like a native Windows application. After all, if we wanted to use Windows programs, we'd just run Windows in the first place and save all this hassle. Your users demand more from you. Do not cheat them out of it.
OK - granted, it would be nice if the games had a distinctive Linux look and feel, but I really don't care about that as much as being able to play the bloody game on Linux. If this is the kind of esoteric touching up that makes it impossible to get a game ported to Linux then I am pissed!! Just put out the freaking game already and take the time to make others Linux-distinctive after you have built more of a market for games running on Linux.
Just my $0.02
AFAIK, virtual tables are about as good as you can get. I've heard of efforts like HP's emulator code that can "flatten" code at runtime, but that's pretty fugging complicated. Do you have any URLs that give more info about the alternatives?
Actually, no, you don't. I know, it shocks me, too... I mean, MS giving away information about their APIs for free?!? But yes, it's true. You can check out msdn.microsoft.com yourself, if you like. :)
What parts of the STL you find to be actually useful? I've written my own list (with iterstor) and hashtable template classes, and find that they give me 95% of the data structure support I need.
STL is a nice design with it's orthogonal algorithms and data structures, but each time I've considered using it, I find myself wondering what functionality or ease of coding I'd actaully get out of it!
I've always been wary of this, because I haven't found a definitive explanation of how the strings are interpreted before being compared. I'm guessing that the intent is to allow naïve to be considered "less" than naked, where it would normally be considered alphabetically "greater", but I don't know for sure. Other than that, I don't use any of your other pitfalls (apart from the occasional signal when I'm knocking up a quick and dirty prototype, but not in production code)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
yeah...and the real problem with McDonalds is that they don't give away Big Macs to people who already bought a Whopper at Buger King.
"The point is one shouldn't need to generate (almost) any code. Never."
You don't need to generate code for an MFC app--it's just much easier if you do. Anyone can sit down and write an MFC app from scratch without the aid of a code generation tool if they so chose. Most would rather not.
"If your API needs exact the same code each time you want to make and MDI app then one should not make source code generator."
The thing is, if you're writing non-trivial apps, you don't need the exact same code every time. You need some minor specialization of the basic code. And this stuff gets tedious--very tedious--to write. Your idea of "new application.MDI()" is fine as far as it goes, but it doesn't go very far. What happens when you want a subclass of the default MDI? How would application.MDI() expose it's message handling architecture for the addition of new messages? How does one control the properties of the MDI window? There are lots of things that MFC can do that your application.MDI() approach couldn't. And that's where the complexity comes in.
Let's try not to let fact interfere with our speculation here, OK?
Thanks for the kudos on the C API bit. I find GNOME code ugly to look at.
GNOME code would be much cleaner in C++ because of the way it merges nicely with a "respond to event" environment like GNOME, or any other GUI for that matter.
I think I remember reading the reason why they balked at using C++ is that they were concerned about making it portable even to environments that didn't support C++.
Inti looks like an interesting framework, will let you guys know what I think when I've had a chance to play with it.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
...MFC stuff doesn't abstract out well. If you use MFC and want to abstract out all but the UI, you're going to have a lot of translation layer code to abstract it. Why? Because MFC does a lot of stuff with strings and such that doesn't exist anywhere else but MFC (Like CStrings...) and you end up using them without an abstraction layer because the layer bloats up the code and makes it even slower than before.
The best policy for someone is NOT to use MFC- it's not the API for Windows, it's an app framework and a bad one for many applications at that.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
In your post that started this thread:
No Linux programmer has even thought of creating a GUI network browser.
After several people pointed out that many graphical SMB clients do indeed exist, you then said:
yeah, but in the 0.0000000000001 pre-pre-pre-alpha stage.
So which is it? Or are you just spouting arguments in the hopes of seeming like you have a valid point?
And just in case people thought you might have a clue about how Unix works, you clear up that misconception with:
In my opinion, only daemons and tty clients should be in textmode.
So, let's get rid of the GNU tools, we don't need grep, tar, cat, man, and the like, because they're all confusing and should be replaced by graphical programs that can't be used in scripts or relied upon to exist on all platforms.
Sheesh.
Methinks you are a hypocrite - you want it free to use in your non free work. In short, a parasite.
KDevelop, btw, has app templates for GNOME apps.
As for KDE's programmers attitudes towards GNOMES programmers, who stole whose HTML renderer without attributing copyright, hmm? Hint - look for KDE names in GTKHtml
In other words, their use of the langauge is not much better that MFC, though at least they don't supply their own compiler. I keep hoping someday they will give out long standing hacks like that and switch to using the langauge itself to do the same thing. Unfortunately, with Qt TrollTech seems to have gotten the mindset that only they can supply platform independent C++ libraries.
--Karl
Two words:
Version Control
Leaving commented out code in the current version of the source just makes it less readable for future maintainers.
I agree that Wine is a bit "thicker" than other layers (mainly because the Win32 API encompasses a lot more than just widgets), but it's not like it's a whole layer thicker, so I don't think it's fair calling it "non-native".
Worldviews come crashing down...
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
The problems with VC++ and MFC are a frequent subject of discussion on comp.lang.C++.moderated--if you're interested in this issue, drop by.
To summarize the consensus there:
the compiler is not standard-compliant and is not likely to become standard-compliant in the foreseeable future. Microsoft seems to regard large corporations as its primary customers and the various versions of Windows, IE, Outlook and Office as its primary products. Everything else is frosting. Unless someone in MS is willing to push the technology in a second-tier product, nothing happens.
MFC appears to be incompatible with the new standard, and as the MS programmers use MFC, there is no internal force driving standards compliance.
Yes, the STL is nicer, more elegant, easier to use, less buggy, etc... In fact, the availability of the STL is perhaps the major advance in programming during the last decade. But, there are a lot of second-rank programmers who specialize in Windows applications and who will never use the STL.
Please remember, MS is software for the rest of us. The bug rate (software faults per KSLOC) in MS software appears to be about 3 times the rate that the Government is willing to accept from anyone else. You get what you pay for.
Thing is, Win32 as an API is a strange, and twisted thing. MS did a lot of horribly broken things within their API and it's not as simple as coding up something that presents the interfaces- there's bugs and design flaws that applications tend to use (Such as VC++ allowing you to alter the contents of constants during execution... :-)
It might seem like a good idea on first blush, but there's so much that's different, so much that MS products let you get away with that's not a good idea that you're better off converting it and making the result work on both platforms.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
And I'd say doing something Fltk might be a better option- because it works the same on both worlds. The same could be said of wXWindows- though I've never seen it in action.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Large amounts of commented out code make programs unreadable. Why was it commented out? Was it test code? An older version? Something that wouldn't compile but needs to be fixed?
And may I ask, what stops you from providing that information in the commented out code-block?
Original quote:
The rest of the syntax highlighting is less important in this case.
You said:
As for comment syntax highlighting being the only usefull part of syntax highlighting, I have to disagree again.
You need to brush up on your reading skills..
I don't think Wine is a good fit here anyway. It doesn't emulate the MFC DLLs (does it?) which means that you would need to get a licence from Microsoft to distribute your Linux game. Unlikely.
--
Business. Numbers. Money. People. Computer World.
#include win16.h and
#include commdlg.h
What eles whould a compiler need to interface with a silly windowing system? A liscence?
Friends don't help friends install M$ junk.
The Loki programmer clearly doesn't understand MFC. he also doesn't understand VC++'s extensions. That's ok, you can't know everything, but that's not a reason for ranting. It's a reason for investigation and to collect information about the topics he doesn't understand.
I've done some tools in MFC and all I can say is that using it is a breeze, but you have to study it to get to that point. That takes time and effort. The Loki programmer should take more time to clearly understand how the original sourcecode is using the MFC.
Another thing though... he's talking about the code to port to Linux. The code he's porting is from people who write tools that do what they want them to do AT THAT TIME, but not mainstream tools for every user on the planet: i.e.: the sourcecode can be cumbersome to understand. IMHO that's a much bigger reason why it's hard to port a tool from win32 to GTK+ than the MFC calls, which are clearly documented in the MSDN (which is shipped on 3 (not 2!) CD's, he must be using old MSDN's too). I mean... how hard can it be to read the clear MSDN explanation of an MFC method, understand what it does and to use an equivalent in GTK+....
--
Never underestimate the relief of true separation of Religion and State.
Take the advice for what it's worth. I feel beter off learning about X.
Friends don't help friends install M$ junk.
Stole? Misunderstood the whole concept of the GPL, eh?
D IFF&subdir=%2Fgtkhtml&file=AUTHORS&rev1= 1.1&rev2=1.10&whitespace_mode=show&diff_mode=conte xt ).
/mill
As for the, often repeated, lack of attribution - can you show some evidence of this? I looked in GNOME CVS and couldn't find any lack of attribution when kthmlw was imported into the tree ( http://cvs.gnome.org/bonsai/cvsview2.cgi?command=
And the suggestions to try the WxWindows libraries are great. Problem is, to be most effective, the original programmers would have to use them. But as Linux becomes mainstream, somewhere a PHB might just lose some pointiness and insist that the game utilities be easy to port to various OS, Linux included.
Bleh!
I remember years ago when I first started programming, we used Borland C++ 4 for windows. When writing a program it included a large foundation of classes called OWL for writing windows based programs. I never got into it very heavily, but years later I learned that Microsoft started to consider Borland a threat and so came out with MFC. What I wanted to ask the more technically adept out there is if MFC won out because it had better merit or was it just a case of Microsoft using its OS might to leverage MFC on the developer community?
yes, that's the dichotomy.
.oO0Oo.
there is no standard to deviate from. In a closed world where everything acts the same one program that looks and behaves differently becomes an obstacle to understanding (however small that obstacle is). Take a look at the new MS media player with it's horrible skins (poor design).
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Yes, thank God. Granted, as pointed out in the article, you're not legally allowed to compile it on non-windows platforms.
As someone who's done a fair amount of programming with MFC before, I don't really see how you could say that. Intended... maybe... but in practice it's not at all.
MFC even has a whole bunch of (very badly designed) STL-equivalent classes that are used very pervasively. This basically means that, if you're doing a decent Model-View-Controller style program you either:
I'm not really fond of MFC in general, either. It's a really poor object-oriented design. It has a horrid set of macros that tend to obfuscate things during debugging, and it really abuses templates (much worse than STL), too.
Since when is it being a Microsoft product an excuse for anything?
DNA just wants to be free...
I have been using Visual C++ for years and have never needed to use MFC for anything. Granted I don't code user interface stuff... but please. With STL there to help out I see no need at all for MFC.
Obviously you have no idea what you are talking about, MFC is a UI library while the STL is a collection of data structures, iterators and algorithms. They are practically unrelated.
PS: I saw this story earlier at the GNOME site, check it out for more insight into porting issues by GNOME hackers.
Second Law of Blissful Ignorance
"GTK+ is C-function-oriented (like Windows API), and MFC is completely C++ OO"
Actually, GTK is object-oriented, theoretically speaking. They just "hacked" an implementation of OOP on top of C (I don't agree with their choice, I think they should've just used C++, but thats besides the point ...) But it's all there .. an inheritance structure, methods for "classes" (in this case structs.) Basically there isn't really a difference between:
struct Goo {};
void Func(Goo *pGoo);
and:
class Goo() { void Func(); };
Virtual functions are a bit different, yes, but they amount to not too much more than using good old C style callback functions, in a certain way.
My point is, you can implement OOP in C, and the GTK guys did just that. It's not very pretty though, you end up with lots of ugly typecast macros etc. But that was their choice, and they had their reasons, which may have been valid at the time they designed it (I had a 'discussion' once on the gimp dev newsgroups with the developers, I was arguing for C++ .. they somewhat rabidly disliked C++ .. anyways ..)
The main difference between the API's, from a design point of view, is that MFC is an application framework, and GTK is a set of objects of UI elements. Yes, MFC has some UI element wrappers, but in the overall design they don't stand on their own very well, and their interfaces aren't well genericized - everything is kind of tangled together in an MFC app. It's difficult to put across what I mean when I say that GTK UI objects are better "genericized" if you haven't programmed the stuff; but I can try elaborate with an example. In GTK, everything is a "widget", and a widget can be given certain base properties and inherit from others, and widget containers can contain any widget. So functionally, you can easily do things like add any sort of widget to a dockable "toolbar" (like the edit boxes and dropdown boxes you see in apps like MS Word or Visual Studio - those things are a pain to try to implement in MFC, since there CToolbar class is not a container, it's a specialized widget that just takes a bitmap and some resource ID's, and I might add can't handle more than 16 colours.) Now, you get this thing called a "dockable dialog" in MFC. Only it doesn't fit well at all into the MFC framework, because after you've plugged a dialog form into it, only the main view can handle ClassWizard messages from that dialog (unlike a regular MFC dialog which gets it's own class) - so nobody uses dockable dialogs, because they're so stuffed up. With GTK it's so much easier, because a widget container can handly any widget.
MFC has so many quirks and fuckups its just not true. Like for example, if your application has a modeless dialog with an edit, and it has the focus, but you happen to press keys for which their are key-shortcut "accelerators", those keys are swallowed. So you have to write extra workaround hacky things into the message pump to test if its a dialog message, and pass it on *to the current modeless dialog* (which you then have to keep track of) manually. How screwed up is that? GTK has no such problems.
What makes Gtk-- different to MFC is, as I said, MFC is an app framework. That means that when you typically create an MFC app you get a bunch of classes that perform typical roles in an application (typically, a "view" class, a "mainframe", an "app" class, and a "document" class.) These are based on the "document-view" architecture, which is something like the model-view stuff you learn in a CS course at Univ. The "mainframe" encapsulates a Windows window, with menus, toolbars, status bars etc - all the "typical MSWord-style application" elements. The "app" encapsulates the overall Windows application stuff, the "document" holds data your program uses (e.g. a spreadsheet) and the "view" provides the user with a visual representation of that data. In theory, this sounds nice and clean, but in practice in MFC it's awful. GTK is somewhat lower-level, and less spaghetti-like .. it provides a bunch of UI components, but nothing regarding tying the stuff together into an application. So the UI elements are more modular, more well-thought-out, more standalone, and generally cleaner and simpler than related MFC counterparts. And toolbars aren't limited to 16 colours .. powerful stuff, this is the 21st century after all (heavy sarcastic tone ..)
MFC tries (and in simpler types of apps, succeeds) in hiding the message pump stuff away from you. So for simple applications, it can make your life quite a bit easier. But nobody really uses MFC for complex apps, because it starts showing its limitations quickly. For big programs (like 3dsmax) companies generally end up writing all their own UI stuff, so they can do "fancy" things like 256-colour toolbars, and get around all the other annoyances and limitations of MFC.
How MS managed to screw MFC up so badly I don't know. I could go on for days about it. Maybe it wouldn't be so bad to program if the documentation was more accurate, I don't know, but if you're an MFC programmer, chances are that days and sometimes weeks of any project are given up trying to figure out either how to get MFC to do something that should actually be really simple if it wasn't so badly designed, or why something in MFC just plain isn't working like the docs say it should. I suspect the only reason they give the source code for MFC out, is that it would be impossible to get anywhere at all if you couldn't spend hours and days tracing into the MFC source code to figure out what the crap it is doing.
I just took another look at SGI's version, but as before find more reasons to stay away than to use it...
You're right that it does specify performance characteristics, but they don't seem that desireable...I noticed that list::size() is listed as being O(N) rather than constant time! Would it really hurt the implementation to require a count++/-- when items are added or deleted? This may seem like a small gripe, but it makes the list class (one of the must useful basic types!) much less useful than it should be - I often use the equivalent size() function of my own list class assuming that it's essentially zero cost.
The other thing that hits me everytime I look at STL is the complexity vs the functionality provided... just take a look at the iterator invalidation semantics of basic_string! Am I meant to remember that stuff? It certainly seems to put an undue burdon on anyone having to maintain code.
If I thought that STL adoption was inevitable, then I might still grumble but start using it anyway, but considering how long it's been out and the current level of adoption, I think maybe that it has risen/sunk to it's own level, and will never be as ubiquitous as it could have been...
cuz you can get more HP out of a well designed 4 cylinder that fits.
Its not. Its a pain in the ass
.oO0Oo.
I'm almost glad to hear it but it's sad that the two widget kits are so awkward.
I've used MFC & the Windows API and the best thing I found to do was to make ActiveX Controls for the logic and Visual Basic for the UI then you get the best of both worlds - and the worst of course.
The winner of course though is *nix 'cos you've got so many to choose from. Non-standard Windows controls make a program clunky no matter how uch better it make the programming. The days or Borlands OWL stuff and non-standard buttons (standard meaning native) just felt plain wrong.
I've tried wxWindows with Python and that was interesting.
What has anyone else tried for fun and seen some promise in?
Obviously the *nix world offers more potential for experimentation with it's abstraction of machine from display.
I'm hoping to start a project on Inferno with it's blend of TK and Limbo (a wierd pascal / c hybrid).
I'm also keep an eye on the Berlin Project with it's 3d co-ordinate system and transparent windows.
Anyone got any direct experience with those two?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
IHBT?
.oO0Oo.
No Linux programmer has even thought of creating a GUI network browser.
anyone that could write one can already visualise it without the need of the machine to help them.
I think Linux needs a breath of fresh air from the real world
it's a good job your opinions don't carry much weight then
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Umm... there is a difference between MFC and Visual Studio. Visual Studio sucks, MFC really isn't bad. I can see the effect of the Borland OWL programmers MS stole on the design.
GTK uses a different paradigm of GUI framework than MFC does.
Anyways, you are obviously confusing RAD tool output and the application framework.
Brian Macy
RTFA. He's talking about level editors, etc. Not games themeselves.
I have been using Visual C++ for years and have never needed to use MFC for anything. Granted I don't code user interface stuff... but please.
With STL there to help out I see no need at all for MFC. If you use it, you deserve the headache of portability problems.
MFC generates Message Maps and macros rather than using virtual functions in its frameworks. The official Redmond Party Line on this is that speed is enhanced by using such an unholy mess. And speaking of unholy mess, sure it works, but you try dealing with scrolling views and having to convert back and forth between mapping modes and you're just about ready to scream "WHY DIDN'T YOU STANDARDISE THIS, CRETIN" at the nearest NT apologist.
GTK isn't OO either - it's a C API.
MFC's strengths don't lie in its technical implementation, but the fact that there is a half-decent application generator that spits out this code. If you want an application with a window, view, document, serialisation support etc etc etc all you have to do is fire up VC++ and run AppWizard.
What Linux development sorely needs is some kind of framework (Inti's a nice start) plus a half decent open source appbuilder that wraps around gcc and gdb. Would you like a default MDI application in KDE? BAM there you go, and INSERT CODE HERE. Ditto GNOME.
Freeing up the developer from pointless busywork is the key. Right click on the class, type in the function signature, BAM, there's your code.
I can here the vi guys choking right now, and some EMACS type is going to chime up that you can actually do that with some custom LISP script, but if we're going to try to leverage MFC leveraging what it does well is important.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
In recent work you've done for us, the quality has been slipping- oh, in spirit it's everything we could ask for, but if we may refresh your memory by this passage of 'Competitive Astroturfing':
Now, where do you get this 'kick in the teeth' language? Isn't that LITERALLY one of the examples you learned in training classes, almost a cliche? You know perfectly well that talk is for the management track, NOT undercover relations. So much of your post was in perfect form- the 'too busy hacking the Cue:Cat' (extra points for correctly spelling its name- elicits subconscious assumption of accuracy elsewhere), the '31337 H4X0R' (textbook assertion of the reality you're paid to present)... it's a shame you blew all this out of the water with your aggressive overtones. Please work harder at staying within the CA guidelines- it is important that this job be done RIGHT, as people are already beginning to not...Doh!
Actually, MS did port it to the Mac. I never used it, but MFC did exist on the Mac, I'm not sure if it still does. If you look at MFC headers, you may still be able to see #ifdef __mac__ or whatever. Piece of crap, nobody ever used it.
Speaking of restrictions, they also restricted what you could build with it, you couldn't make any MS Office type programs with it (WP, spreadsheet). No competition, please.
I'd be far more interested in porting my applications from GTK to Windows. That would let the MS serfs a taste of freedom and would also significantly enlarge the userbase of my program.
I haven't used the Win32 version of QT, so I can't say how well/poorly it deals with these sorts of differences, but it seems to do a little better than GTK/Win32 does at this point, but still doesn't produce a truely native looking app without some real work on the developers' part.
IMO, it's easier to work with a program that looks like it fits on your desktop, rather than one that just looks like original program on the original platform, trapped in a native-style window.
I used up all my sick days, so I'm calling in dead.
I've found egcs to be unusable for some of the more advanced template stuff. In particular, implementations of the standard C++ library - as opposed to the stone-age libstdc++ that comes with g++ - simply crash the compiler. My team had to move to g++ 2.95.2 for this reason.
On the other hand, version 2.95.2 chokes on some perfectly legal constructs that egcs could compile just fine. The crucial difference is that we could work around the new bugs, whereas we could not work around the old ones in egcs. So, switching to 2.95.2 was a win overall.
From all I've heard, MFC is a total nightmare. Does anyone actually use it for game-programming? Ok, maybe it's great for building an installer or something - but a FPS? How and where is it used?
Can anyone with actual experience (as opposed to my IANAgameprogrammeronwin9x disclaimer) comment?
Can your IM do this?
You could just distribute the MFC DLLs (in Win32 native format)... You DO have a license to do that if you own a MS development tool (I don't).
I used up all my sick days, so I'm calling in dead.
I used MFC for a fairly large project... it wasn't too bad at all. When I first looked at it I nearly puked. After a while, it became clear for for UI's, it is golden. One important thing to remember when using MFC, don't try to think too far out of the box. (Don't try and bend and twist the framework too much) That leads to "interesting" bugs. :-)
Overall, I thought it worked okay. But the MSDN doc is VERY VERY useful.
Peace out.
One of Java's biggest strengths is its cross platform GUI ability. No need to deal with MFC and GTK. Just deal with AWT (or if you are willing to ditch the mac, SWING)
When you combine java jar files with some simple VBS scripts or some bash shell scripts, you can even make installation pretty seamless nowdays.
While this article deals with porting from MFC to GTK it seems to assume that the MFC finished product is what you're starting with. This is fine, but the situation can be much easier if you have a little forsight in mind when programming your original MFC application. Simply, it's called abstraction. Abstract all your UI functions and then write an MFC implimentation of your UI interface classes. If you then need to port all you have to rewrite is the implimentation classes. If you did it right, all your abstract interfaces won't have to be rewritten, and you won't have to spend time reprogramming behavior, just straight UI components.
I don't use STL directly.
OSE library (which I highly recommend) provides some STL facilities: universal iterators, rank actions for arbitrary objects, etc. - but IMHO is easier to use than raw STL.
Blitz++ to my knowledge uses valarray and lots of template programming.
there are graphical browsers...
http://freshmeat.net/projects/komba/homepage/
Hrm, okay. I stand corrected on the MFC licensing issue, then. We're still at VC++5 at work for sundry reasons.
DNA just wants to be free...
Besides, Loki already see Qt as a great option, as documented at:
http://www.trolltech.com/compa ny/ announce/loki.html
--
Warwick
There is a defacto syntax for assembler. it's called "C".
N. --
Standard, cross platform, open source gaming library:
:)
Simple Directmedia Layer.
http://www.libsdl.org/
We use it for all of our games. Now if we could convince the rest of the world that this is a good idea.
--ryan. (icculus@lokigames.com)
Don't say, "don't quote me," because if no one quotes you, you probably haven't said a thing worth saying.
He obviously has some good issues to bring up but I question his abilities as a C++ developer.
1) GCC 2.95.x... the only compiler that gets close to it in ISO compliance is the Borland 5.5 compiler. Getting confused over earlier errors... that happens... all the compilers have their areas that are bad. At least he could have complained about GCC being dog slow on C++ code.
2) MFC vs GTK... he's complaining that his joystick isn't a mouse. First... the frameworks are similar in their design at a basic level (they both let you write graphical applications with similar capabilities). His biggest complaint is that MFC is a message based framework and GTK is functional/callback based. Whatever... in the end both call functions based on "notifications"... they just have different ways of specifying it. If he can't comprehend that he has some other more serious issues.
But I would agree the porting is a bear but it ain't MFC's fault. And interstingly enough... I don't see where he says why he doesn't use GTK for Win32 if he finds MFC to be such a bare. I know why I wouldn't but you'd think that would be an obvious question.
Brian Macy
He's not talking about GCC. He's talking about
Linux.
If Linux used standard C then it should compile
using ANY standard compliant C compiler. But it
doesn't.
It's just hypocritical to complain about standards
when you're not even practicing what you preach. It seems the people who complain loudest about standards are the ones who have no real work to do.
MFC sucks. Why bother with it? If you really need an "application framework" then write it yourself and plug in code as you need. Don't spend months on end learning how to press buttons in somebody else's clumsily written macro generator. I could write a high-level API for Win32 as easily as I could learn one. I have written a fair number of programs for MacOS using the same application framework (which I designed myself.) How many times do you need to rewrite the event handler for a click in the menu bar? People who use MFC as professional programmers are just following the company line. People who use MFC for their own projects are just stupid.
"Any connection between your reality and mine is purely coincidental." -Slashdot
Well, you realise that you're just about developing for Windows ONLY with that kind of approach.
ATL is nice inasmuch as you're not carting around the enormous baggage of MFC and all it entails with you (big DLL) esp when having to move instances of interfaces between machines.
Just remember when dealing with ActiveX you're dealing with an interface and not an actual object, and you'll be OK.
Oh yeah, keep in mind that BSTR and OLECHAR* are not the same thing, even though the compiler won't be able to tell the difference, and one's typedef'd as the other, and it works in a lot of cases.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
I'm not going to disagree about your assertion that MFC is non-portable or that their C++ compiler sucks. I completely agree... I couldn't even use their compile until VC++ 5 sp3 and even then I still have to turn off my inline template specialization optimizations to prevent hundreds of errors that I force to warnings with some flags.
My point was the poster was saying that MFC sucked because the RAD tools generate files that say "don't touch this" or other non-sense. That has nothing to do with MFC... then when you add in the reference's to GLADE it is obvious the poster didn't understand the difference between app framework and RAD tool.
Brian Macy
I make this point because some people reading don't get that.
Check out ioquake3.org for a great, free, First-Person Shooter engine!
Try converting Motif stuff to Windows. It will be as hard as porting MFC to GTK. Nothing's wrong with MFC: You don't do GUI stuff directly using the Win32 API as you don't write X apps using Xlib...
yeah, but in the 0.0000000000001 pre-pre-pre-alpha stage. There really should've been more demand for GUIs in Linux. In my opinion, only daemons and tty clients should be in textmode.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
MFC may be good for windows, But it all goes back to Microsoft's attempt to shut everybody out of Windows. Just like they did to J++, they have made the MFC and Visual C++ GUI classes so tied to Windows, its almost impossible to "digest" the code without 2 or 3 MFC and Windows API manuals. MFC is simply a C++ wrapper for the standard Win32 API so that people who want to write code for *WINDOWS* do not have to use the awkward Win32 calls anymore. No thought of any kind about platforms other than Windows! So what if MS hadn't developed MFC? Your code would have been portable and not bound to Win32? NO. It would have been Win32-only too. Actually, MFC makes your code less Win32-specific since IN THEORY the classes might be rewritten for a different OS (AFAIK MFC code might even be ported to Mac, albeit with lots of restrictions). MFC just offers you some comfortable classes and an OO approach to the Win32 API calls. Creating windows, device contexts, and GDI objects is considerably easier to perform in MFC and less error-prone (the class destructors perform some cleaning up which all had to be done by yourself in standard Win32 code). Hey, I'm not married to this MFC thing, I've even talked my boss out of using MFC in our current project, but I still get the idea of MFC and I'd say that for Win32 applications it ain't bad.
Then I guess gcc is broken also. People can't use compilers other than gcc to compile the linux kernel because the linux uses non standard extensions that gcc provides and other gcc quirks.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
If you're using a temporary list to hold an arbitrary number of things prior to allocating an array to store/access them more efficiently it's useful to know how many elements you have, as it is if you're using one as a queue and want to trigger code based on high/low threshholds, or even if you're waiting for a list to become empty, but want to know how many items are still left... Perhaps more to the point though, a library writer (esp. a basic data structure library) shouldn't make lazy/sloppy assumptions about how it's going to be used.
I agree with you about C++. I think the problem isn't just programmers who don't fully understand some of the more complex features, but also incorrect and incomplete implementations of the lanuage.
Hm.... this is all so common these days. Obviously you have never used VC at all, if you had, you'd know it's just an IDE for a C++ compiler like Watcom, Borland et al. You are basing your opinion on functionality on the fact that it's Microsoft software. I have developed portable code in VC that compiles with GCC and such compilers (even Amiga ones like SAS/C) without any difficulty at all. Your claim VC makes code Windows only and Microsoft specific is garbage.
MFC was Microsoft's attempt at making Windows applications easier to write back before better tools were available. Specifically, C++ had not been standardized yet and the Standard Template Library (STL) was neither official, widely used, nor commonly implemented by most compiler vendors. So Microsoft did a lot of what appear to be funny things, like creating their own container and string classes, and so on.
Since then, Delphi and Visual BASIC and other GUI creation tools have become available. They're much, much nicer than dealing with MFC. That's what most Windows programmers use these days. It's silly to muck around with MFC when someone can bang-out a UI with C++ Builder in much less time. Very few people like MFC. It's still used at Microsoft for legacy reasons, and you'll find some die-hards who refuse to bow down to nicer tools, but for the most part GUIs and such are done with VB, Delphi, Builder, and so on. Heck, even Microsoft uses VB to write installers and such.
Complaints about MFC are valid, just as they were valid five years ago. This is nothing new, and nothing to get all worked up about. Heck, Xlib sucks too. We all know that.
Gtk+ is object oriented. Gtk-- is a c++ wrapper. Just because it's not written in C++ (or a so called object oriented language) doesn't stop it from being object oriented.
I.e., there's even more reason to keep the old code around, because you won't just be doing the original porting, you'll be porting the bugfixes as well.
Version control isn't good enough anyway. Commenting out the code makes it clear which piece of old code matches what replacement code. And when you want to do something based on the old code, you can search for that code, then find the new code that was written to replace it.
Programming rules are just suggestions, not laws. If it makes sense to break a rule, then you should. I know I would much rather maintain the ported code with the original code in comments.
--
You need to stop being so selfish. If you don't want to pay for two games only buy the linux port. The people at loki have to make money, since they can't live off a good feeling inside for just porting it to linux. Games are now getting where the linux and win32 versions are released together in a timely fashion, and in some cases both releases come out at the same time.
Some of these guys work seven days a week, and they don't make as much money in the small linux market as they would if they were working for a win32 game company. After buying the rights to port and etc, they have to sell so many copies just to break even on that title before they get profits. Also Loki games have value adds, they fix bugs in the win32 versions and in some cases add extra features. A good example is Sim City 3000 Unlimited they added scrolly mouse support and fixed some show stopper bugs as well.
If you want games on linux you need to support them with your money or even with help on SDL, OpenAL, etc. You can stop buying win32 games and only buy linux versions - suck it up and only play the win32 demo until the linux release if you can't buy both.
- Mongoose
--
have you hugged a mongoose today?
What kills me about MFC is that it's not just one OO system, but at least THREE layered on top of each other.
The first layer is Win32, which is an OO system extending C/Asm. It uses strings as class identifiers that are created at runtime, and numeric method/event identifiers that are distributed through hierarchial switch statements. Half of it runs in the operating system, and half of it runs in your app, a combination that is extremely confusing and difficult to debug.
MFC is a C++ wrapper around this. The problem is that C++ classes are fixed at compile time, C++ names can't be exported to a C app (and hence can't be called from kernel), and it uses virtual tables (arrays of function pointers) instead of switch statements. MFC is largely massive hack to make C++ and Win32 coexist. The C++ CWnd class creates matching HWND handles to the Win32 classes, and translates between the two OO styles. This translation is by no means trivial, and as others have mentioned it involves massive macros and templates, and all sorts of custom extensions and language abuse.
Just when you though it couldn't get any worse, Microsoft came up with OLE/COM. COM uses 64 bit GUIDs to identify classes that can be running anywhere, even in another process or computer. It imports platform/compiler independent virtual tables at runtime, uses assembler hacks to get the function call translation going, etc... One of the big disadvantages of COM is that it's not really an Object Oriented system, but an Object Based system. It uses classes, but it's very difficult, if not impossible, to subclass from them. For example, DirectX is a popular COM based API, but I've never heard of anyone subclassing from, say, IDirect3DDevice7. COM requires some pretty strange things, and all of this has to be interfaced to C++ too, while maintaining compatibility with Win32.
In my experience, programming in MFC is mostly cut-and-paste from the help, because it's practically impossible to work out the steps required to accomplish any given task. Sure, making a dialog box with a few standard controls is trivial, but if you want to step out of the given bounds in the slightest way, you're up the proverbial creek without a paddle.
--
"If you would be a real seeker after truth, it is necessary that at least
once in your life you doubt, as far as possible, all things."
I have developed portable code in VC that compiles with GCC and such compilers (even Amiga ones like SAS/C) without any difficulty at all. Your claim VC makes code Windows only and Microsoft specific is garbage.
Congratulations, you beat up VC's defaults! It's can write code that compiles with GCC under notepad easier than I can under Visual Studio. By devault Visual C++ TM, Wizards TM you through creating a MFC piece of junk that might be able to run under WindBlows. If you spend a few hours working with it's poor interface you can make it work like a normal editor. I have used that piece of crap too.
My points were that MFC is not prortable and Visual studio is a pain to use.
Friends don't help friends install M$ junk.
Remember PALASM or Verilog ? The first hardware description langage were proprietary but anyway it did benifit to everybody because hardware designer could work at a more higher level.
It is strange that Brian (who was active on wxWin lists and, if I'm not mistaken, had the cvs access himself) didn't tell us anything about this before but chose to comment here.
Anyhow, the comment contains at least 3 errors:
1. wxWin license is not LGPL and so it isn't invalid
2. there is no code from GPL libraries in wxWin to the best of my knowledge
3. "messy makefile" is totally false
And I don't know what was meant exactly by "extremely bad C++ programming practice".
You don't know shit about MFC. It's for normal GUI stuff. First person shooter or any serious game is written with the help of DirectX
Obviously that fellow misunderstood a word somewhere along the way. Give that poor dude a dictionary and an E-meter, quick!
If tits were wings it'd be flying around.
My company was contracted out to port some Windoze based UPS monitoring and control software to various UNIXes. Won't tell you who, but their hardware and software both suck.
The project was planned at the outset to be cross platform, but they used MFC (mistake #1 of many). MFC is not much more than a wrapper around Win32. The greatest advantage you get is that they combine alot of calls. I don't have to call every kernel function, an MFC call will aggregate a few. So when commenting on MFC, comment on what it's designed for, aiding people using the Win32 API. It is not true OO, its a C++, class based abstraction layer on top of C and Win32 procedural calls and data types. Can debate whether it's a good abstraction layer (I personally think not) but at least critique it in the correct context.
Now, what we did is was rewrite non-GUI classes, and swap out the GUI classes with wxWindows, which seemed to be designed by someone very familiar with MFC, and had a lot of 1-1 mappings. Can't comment on wxWindows, I was using 1.4 which was bad (and yes I do realize it's open source, and I did contribute back) but haven't touched it since.
It wasn't hard, just time consuming. I'm thinking the game folks could do something similar for their old stuff (MFC lib on Freshmeat anyone?), and start Qt or V or whatever for their new stuff.
BTW: The only system clock we could find in Win32 for uptimes had something like a 14 day rollover. Hmm, even MS think s you need to reboot once a week.
Maybe "never comment out code" is a good rule of style for source once the original author lets it go, but it's just style. When doing a port or conversion, you'd be throwing away good information not to leave commented code.
--
...the serious lack of graphical user interfaces in Linux. Seriously, smbclient has been sitting in text-mode hell ever since it was created. No Linux programmer has even thought of creating a GUI network browser. Ever tried pushing a Linux programmer into building a GUI into his work? "Sorry, can't do that, too busy hacking the Cue:Cat!"
:) Flamebait can, at times, be useful :)
:)
Good lord I can't believe you have a +1 bonus. Someone should shoot the adminstrators for allowing this to happen.
First of all, there is no lack of graphical interfaces on Linux, there is a proliferation of them. Be more specific. There may be no good graphical interfaces(in your opinion), but that does not mean they don't exist. And there ARE nice graphical front-ends to smbclient. My favorite is LinNeighborhood, and an old stand-by is xSMBrowser. There. Not only have Linux programmers thougt of creating a GUI network browser, but they DID. Shut up please, I don't like your ignorance. And you want to push a Linux programmer into building a GUI into his work? Why the hell don't you pay him, smart-ass? Or, better yet, why don't you do it yourself you lazy bastard? Most of these programmers are doing it for FREE. You want something, you pay for it. I'm sorry, but I'm not going spend years of my life trying to please you because you TOLD me to(have you ever ASKED for a feature in a program, as opposed to demanding it?!?).
Contrary to what you may believe, Linux is for getting work done. That means that if your hard drive failed, and all but 8 Megs of memory has been destroyed, you still have a deadline. What are you going to do? Go out and buy a new computer, spend hours setting it up, etc., etc., or are you just going to pop in that rescue disk you made last week to finish off what you started? I'm sorry pal, Linux was not designed from the ground up to be what you want it to be. Go somewhere else.
[big sigh]
Ahhh... That felt gooood
Have a nice day
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
http://freshmeat.net/projects/xsmbrowser/homepage/
And whats so bad about text interfaces? Their quick, scriptable and expanable. Build whatever kind of GUI you want on top of it or don't. Its up to you, you're not tied to some guys idea of what an easy to use interface is.
Bother.
Sounds like fun!
Can we try porting my Ford F 150 engine to my Volkswagon Beetle next?
"Imagination is the only weapon in the war against reality." -Jules de Gautier
In my opinion, only daemons and tty clients should be in textmode.
That would make a Linux box completely useless remotely, or without an X server. The power of UNIX is in its command line. If you like a system whose functionality is inseparable from its GUI, Microsoft would love to sell you a copy of NT.
And there are lots of GUI frontends to SAMBA and the like. I don't feel like searching them out, you can do your own homework. But they're there.
--
Valid, but only assuming that you actually care about portability. Not everybody does. Microsoft obviously doesn't.
I've developed quite a few solutions for various clients using MFC. They were not portable -- nor were they meant to be.
--john
I am not joking. From the article:
DNA just wants to be free...
I'm sorry, but this is nuts. MFC is the worst example of OO UI that I have ever seen.
If you really buy into Object Oriented dogma, and you want to make an OO UI, you have two places to look for real examples:
Unfortunately, I can't speak for QT; I've never used it. {:(}=
Now MFC..?! An object oriented system? It's the epitome of bad OO design. Good lord; when you use MFC, it generates these enormous files for you with macro blocks that say, "DO NOT TOUCH THESE!" around them. You can't add anything except through the grace of the UI builder. Is this "modular design"? This from people who mindlessly repeat the mantra "We must have type safety"?! It's nuts. Okay, now lets move beyond the macro blocks. When you are using MFC, it generates functions for you, and you are supposed to manually modify these functions. You can't register your functions; you have to manually go in and modify the code that it generates for you. And we are supposed to believe that this is "object oriented" design.
I'm not an OO bigot. But really; If you have determined to be an OO bigot, at leastbe a good OO bigot. Pull out your SmallTalk books, Simula, Design Patterns, Objective-C. Trace your roots. Read them. Read about NextStep. Study. Look at well documented, and well implemented, OO UI designs. Please. I'm begging you. As much as I despise OO facists, at least I want to talk with quality OO facists. Please don't align yourself with MFC.
(I generally hate writing flames, but some just have to be written...)
I will not ever buy a game ported by Loki.
Sure, they've got a great installer, and perform excellent porting of even the most complex of games, but I refuse to pay for a game twice. You see, I run Windows AND Linux. The only reason Windows resides on my machine is for multimedia and games - mainly because it has a wider selection, and very little of my game collection has FREE Linux binaries available. And until recently (I upgraded), hardware acceleration was not an option for me in Linux. (Which is a whole other rant entirely).
As such, when I buy a game, I buy a windows game.
IMHO, Loki is just adding to the problem of a lack of Linux ports - there are too many people of my point of view to make it financially viable to ever take the Linux gaming market seriously. If Loki really wants to increase Linux market share, then they should stop asking the gamers to pay for their games a second time. Release the binaries for free (as in beer), or at a minimal cost (preferably less than 1/3 of the original). Of course, how would Loki then gain income? It's a gamble, once the market share is there, then perhaps companies will start to pay them the required funds.
In a similar token, I will never pay to play a game I payed $70 (CDN) for.
Bring on Neverwinter Nights!
-Medgur
Fight Spammers!
I've written my own list (with iterator) and hashtable template classes
What you mean is that you have wasted a significant amount of time and effort reproducing existing functionality.
I am also sure that your code contains bugs, has non-optimal performance and has an interface that no-one else will ever be bothered to learn.
The STL provides bug-free, consistent, guaranteed-performance templates. It is also well-understood by all professional C++ programmers.
Has the entire point of code re-use passed you by? Have you completely misunderstood the standardisation effort?
Strong advice: Use the STL. Do not hand-roll your own. Otherwise, you will never get a job coding C++.
Share and Enjoy.
Nice, Brian, next time try to get more info before writing this kind of misleading posts. wxWindows is not LGPL, so I can't see how can it be "invalid LGPL"; if you don't like the license, too bad. There is no copied in code from GPL libraries. The makefile system is not messy at all, much cleaner than most open source projects out there (it's not anyone's fault if *you* can't understand it), and I'd really like to know what do you call "extremely bad C++ coding practice". Regards, G.
What exactly do you think that can't be done? Nothing prevents you from writing platform-specific code at will, so I'd say that this statement is false. And regarding the overhead due to using "an emulation" (which is not really what wx is), why don't just try and give some real figures?
Regards,
G.
>It is strange that Brian (who was active on
>wxWin lists and, if I'm not mistaken, had the
>cvs access himself) didn't tell us anything
>about this before but chose to comment here.
Yes... I had CVS access... thought it was insane that I was given it days after I started working with the project. Again this points out my organizational issues. And I believe I voiced *all* my concerns on the list and was essentially ignored.
>1. wxWin license is not LGPL and so it isn't invalid
Please read this:
http://www.wxwindows.org/licence3.txt
>2. there is no code from GPL libraries in wxWin to the best of my knowledge
Please read "EXCEPTION NOTICE" #3 at the above URL
>3. "messy makefile" is totally false
That of course is a matter of opinion... the fact you have to link in a couple dozen win32 libraries just to use wxWindows is just one of the messes.
Brian Macy
[...]
> That of course is a matter of opinion... the
> fact you have to link in a couple dozen win32
> libraries just to use wxWindows is just one of
> the messes.
[...]
Sorry? How should this work without the libraries?
Even for core Win32 API apps you'll have to do that.
Except console apps, of course.
Have you ever tried to tweak your setup.h?
MFC 4.2 is the current version of MFC... Visual C++ is on v6, but MFC is 4.2. The author is wrong.
I'd agree with you if it wern't for the fact that I've yet to come across a library that used STL as part of it's interface! In fact, the only C++ (vs C) library I'm using right now is Qt which implements it's own datastructure classes!
Are there any/many libraries that you're aware of that do operate on STL types?
Gtk+ seems fairly object oriented to me, although I've only played with it. Using an OO language does necessarily mean you are doing OO; conversely it is possible, although awkard, to do OO in a language that does not directly support OO (like C). OO is more than just syntax. In gtk+, I can NOT do this: Widget* w = new Button; w->show(); Instead, I have to do something like this: Widget* w = button_new(); widget_show(w); The syntax is not OO, but the design is. Widgets are split up into an inheritance hierarchy, and the exact 'show' method is selected at run-time based on the concrete type of the object (run-time polymorphism). I much prefer doing OO in a language that supports it directly. But ironcially, Gtk+, written in C, is actually much more object-oriented than MFC, which was written in C++.
Stephen Molitor steve_molitor@yahoo.com
[W]ork is being done (by TTimo's team at QERadiant.com) to make the existing Q3 tools cross-platform with a common code-base by porting the Linux GTKRadiant port Loki developed back to Win32 (they just recently made their first Alpha release)
;-)
Until TTimo's team includes a Mac programmer (these people are making some noise about it), and until someone can work out the uncertain ground between GTK and OS X (here's one step in the right direction), this should probably read "somewhat cross-platform."
The article is full of twisted comparisons and faulty information. I develop for Linux, other Unix variants and also Windows 32. The first thing that jumped out:
"...no one wants to run a native Linux application that looks like a native Windows application. After all, if we wanted to use Windows programs, we'd just run Windows in the first place and save all this hassle."
Am I missing something here? My customers and I want an application to work. Period. I don't give a flying fig if it "looks" like a Windows application. The "look" isn't whay I run Linux at home. The "look" provided by either Gnome or KDE or whatever is NOT the reason I run Linux, that's for damn sure. The ability to have a decent GUI and at the same time run all kinds of other nifty programs at the same time is why I run Linux. I only WISH the latest Mozilla milestones "looked" like the old Navigator.
And the MSDN Library consists of 3 CDs, not 2. He'd know this if he actually followed his own advice and kept one handy and used it once in a while. This guy is full of crap, IMO.
Perhaps you should read the quoted text and my reply. I was just pointing out the fact that gcc has proprietary extensions and that the linux kernel uses them. By the original poster's declaration, gcc is broken.
BTW, there are other free compilers out there, lcc is one.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
I've never seen any performance guarantees for the STL. AFAIK any implementation is free to implement the standard in any way they choose, and I'd be very surprised if they all (for example) chose to implement hash tables the same way. OTOH my hashtable uses insert-at-start chained overflow, so I know precisely what the performance characteristics are.
;-)
I don't know why you'd think my code has bugs or a hard to learn interface. I've been programming since probably before you were born, so I think I've got the hang of it by now!
Your other points are equally dubious...
Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's? Whichever you use? Them all? The fact is that aspects of the STL String class can be formally proved to be unimplementable without bugs, which is why the Rope class is preferred.
STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL.
AFAIK (certainly at companies I've worked at), STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either. Maybe I'm not the only one to find it of limited value...
Of course, another approach to the problem would have been to write the program in a portable library in the first place, and simply recompile it for the intended target platform, be it Windows or Linux.
I have seen this being done with a reasonably large project using the Qt 2.0 library. All development was done in Linux, and the project was later "ported" to Windows in the course of two days. Printing and some obscure font sizing problems required a bit of meddling, and several wrong assumptions and oversights were uncovered in the porting process, which turned out to be genuine errors in the original code. But all in all the project was easily converted from Linux to Windows with minimal effort.
The project (producing a 4 MB binary) is still being developed, in Linux, and regular compatibility testing is being done on the Windows platform mostly using vmware. All in all the money for the Windows Qt License and the vmware was well spent, as developing in the Linux environment still is much more comfortable, and debugging is easier, despite the shortcomings of the g++ compiler pointed out in the original article.
© Copyright 2000 Kristian Köhntopp
... that whole attitude of "Good gods, I don't want anything that even loks like windows anywhere near my linux box" is a fair summary of the maniacal anti-microsoft rantings I hear all too often from linux fanantics. And while it is clearly illogical, well, there's a reason "fanatics" applies...
He is being pretty silly, though. Isn't QT designed to look like an MFC app? I might have that wrong...
Anyway, I have to agree that saying that the problem lies in a linux program which happens ot look like a windows program is absurd. Refusing to use the app because of this reason is even more so.
-J
Karma: T-rexcellent.
Hey, there.
I saw your response to my article on Slashdot:
(http://slashdot.org/comments.pl?sid=00/10/01/1422 222&cid=16)
Just wanted to let you know what I think about performance:
1) GTK+ tends to use a lot more stack space for signal handling, mostly for making more function calls. You can get a good 13-20 stack frames deep in signal handling. This is, honestly, nothing, but it makes Windows a little faster in this case. This is partially due to the fact that GTK is a little more flexible, and partially due to the more-flexible design of X. To be fair, you probably aren't going to notice a difference even on a 386, unless you are passing a LOT of signals; and unless you are using some bogus message passing scheme to transfer a file via signals or some other insanity, it isn't going to matter.
2) Most of the programs that use MFC or GTK are NOT speed-dependent, at least not in their signal handling, so it's moot.
3) This leaves one area, and I cover it in the article; Bitmaps verses Pixmaps. Bitmaps are faster, but that's the tradeoff you get for being able to separate the X client from the X server. I tend to think that a bitmap will also be faster than a GdkImage (which is a wrapper over an XImage), especially over a network connection. If you were to do some serious animation in GDK using GdkImages, you'll probably find an equivalent program written to use Win32 bitmaps will be a little faster, but again, this is a contrived comparison, because for this, you'd really want to use DirectDraw and/or SDL or something else.
In short, if MFC is faster, it's not by much, and it's basically not a problem anyhow. :)
Hope that's helpful.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
the documenation is often very sparse and it's chock full o' bugs. The only way I really enjoyed using MFC was when I was working with a guy who essentially forked off his own version, which allowed us to fix bugs and make enhancements. Also, that made it easier to keep working without CrapStudio and all that automated stuff that generally slows me down and makes the code look really ugly. MSVC++ is a pretty decent environment as long as you stay away from the automated stuff.
You are in a maze of twisty little passages, all alike.
It's *very* similar to MFC which coming from an OWL/Windows development background I like. But the whole project is a mess... invalid LGPL license, anyone who wants to help is given CVS write access, copied in code from GPL libraries, a messy makefile system, and extremely bad C++ coding practice in general. Without much better project management wxWindows will not be suitable for production applications.
Brian Macy
Why porting from MFC for new software... if you plan a port for Linux, you'd better directly start using QT for both OSs instead of MFC/GTK.
I have used both OWL and MFC, and in my opinion, OWL was better technology - it was entirely C++ and didn't rely on a "framework" consisting of classes, macros, and special "dependencies" that only the compiler knows about. OWL, on the other hand, used the C++ OO paradigm, and it was very easy for a C++ programmer new to windows programming to get a windows app developed in a short period of time. Unfortunately, though, OWL covered only the most basic of windows classes, so when Windows95 came out, it became pretty much obsolete. And then there was the AppWizard in MSVC++, which shortened application development times drastically for those familiar with MFC.
What really happened is that programmers gave up the ease of development with OWL for the features and shorter development times with MFC and MSVC++. MFC has a very complex and idiosyncratic interface - but, provided that the application programmer can handle the complexity, it is a much better RAD tool than OWL.
Unfortunately, the Linux community has been blind to all of this. What Linux needs is a standard graphical interface with a standard RAD tool. Face it - there are no GUI development tools that run in Linux that have even come close to offering the features that MSVC++ has - AppWizards, ClassBrowsers, integrated resource editors (AppStudio), syntax highlighting, and a standard application framework for rapid application development(MFC). Until the Linux community responds to the needs of the larger development community, it will ever be a niche OS.
The society for a thought-free internet welcomes you.
That *might* be true, except that you are forgetting just a few small pieces of blatantly obvious information:
1. GCC itself has not only been ported to gobs of platforms, but it also cross-compiles.
2. GCC is open source and freely modifyable.
3. The Linux kernel does, in fact, compile on gobs of platforms.
Go home already,
-OT
Because you can ...
MFC and Visual Studio are traps to be avoided. Writing anything with Visual Studio is akin to using Visual BASIC. You get robot code that says, "for heaven's sake, don't modify this" when you can find the pieces. MFC is just a RAD wraper for the win API, an interface that was easy to begin with. Bloaty barf! MFC instantly bloats simple apps to 10 times their original size, and leaves your nads in MS hands for future breakage. You don't think MS uses MFC, do you? Or is that how Win2k got so big? Nothing is easy when things are hidden.
Friends don't help friends install M$ junk.
Well, considering that MFC has HORRIBLE performance, I doubt that there would be a porformance loss in porting from MFC to GTK.
"The price of freedom is eternal vigilance." - Thomas Jefferson
MyopicProwls
MyopicProwls
My homepage
From the article:
"The Microsoft Foundation Classes are going to be 90% of your porting headache. Games generally don't use the MFC, so usually most the bulk of that porting work is focused on generating Linux-based graphics and sound drivers to integrate into the codebase. This is why the editors take longer: you have to deal with an almost-certain code rewrite when you encounter MFC code."
So, to answer your question, MFC isn't used for the games. It is used for the editors. But congrats on getting 5th post. Shows you spent time to think before posting. Next time, read the bloody article before you post. Thanks.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Where are my moderator points when I need them?
By that definition, most environments are broken. There are Win32 extensions to perl, so that's a broken development environment, to give a less exotic example than the kernel. Java has the microsoft packages.
There will always be local extensions to your development enviroments. The trick is to know when to use them and when not to use them.
Maybe of greater concern is that developers are not usually very careful to ensure portability. Do you use sysconf(3), [f]pathconf(3), et al. a lot in your code? No? Do you still use strcmp(3) instead of strcoll(3). Anybody still using signal over sigaction (shudder!)? How about alloca, mknod, or vfork from BSD or [dej]rand48, popen, or remque from SYSV? Even ioctl is not part of POSIX.1 -- ever used it? Then don't worry about the development environment: worry about your code first.
Hi!
Well, I doubt a good standard graphical interface will be possible until the nightmarish, out-dated hack that is X finally dies. I wish BeOS had gone the open-the-source route instead of the web- appliance route (of course, wider acceptance of proprietary BeOS would have been best. A BeOS based GUI on top of linux still leaves you running an insecure, unstable Minix derivative. This, however, is a different issue, and is probably more than enough to get my post modded down).
As for standard RAD tool, well, Borland Delphi for Linux will be available by the end of the year. Or, if you're not an Object Pascal fan (your loss), Borland C++ Builder for Linux will be out Q2 of 2001. And, of course, Borland JBuilder already runs on linux.
Well JBuilder offers all these things for Java and it's been out for about 9 months, and, assuming that Kylix will be similar, the same thing will be available for Delphi and C++.
so write them and stop whining.
Sure you could provide that information in the code block but it still kills readablity for future maintainers. Ever try to read a word doc with track changes turned on? Files with commented out code are similar. They end up looking like some kind of rough draft of code, not "final draft" code. /* Code below worked on windows but doesn't here so rewrote ..... */ .
My feeling is that if you couldn't hand it in to your college professors in school, why should you do it in life? Just because you are not getting graded does not mean you should be lazy. Take the time to use a source repository and use check in comments. If you check in changes often with good comments, you can figure things out much easier then just leaving comments like
Yes, you are right aobut the syntax comment. I took it a bit farther than the author may have intended. But I really disagree with that even being the most important part. As I said, I like seeing all the different parts of the syntax colored differently. It makes the code easier to follow and look more structured. Comment highlighting is usefull but it is only a part of the whole.
-- soldack
Sure you could note why you commented it out but does this make the code any more readable? You could just as easily check in the original code into CVS (or something similar), make the changes, check in the new code with a nice CVS comment. Then you could later use cvs diff and log to see the history. Think long term and think about other maintainers. Commented out code may work for you or for a quick kludge but it will get pretty bad as time goes on. File sizes will swell and there will be no chance of making one set of source.
If you really want to see both sets of code, try using something that could result in one set of super source that will compile anywhere. I work on software that builds unmodified on Linux, BSDi, FreeBSD, Solaris, Irix, AIX, and NT4/Win2k. There are various methods to handle bits of code that must be native. You could try general public view classes with native cat classes beneath. Or for a more c style solution try general api frontends to all native functions. The native functions are then implemented in special native only files. For example File.cpp is a general File API but FileWin32.cpp implents file handling for Windows while FilePosix.cpp implements File handling Unix style. Throw in configure script or make handling and your project will adjust to use the correct files for the correct platform.
By seperating the common from the native only code, you improve readability, establish a common API, and make future changes easier.
As I said, I wrote code like this everyday. It works with everything from back-end code to UI code. Trying to maintain commented out code in some sort of "port the original's changes" becomes very difficult. When the original changes you have to match his changes with your commented out changes and then rewrite again? ARG! I have seen places try to walk down that road too many times. It doesn't work well at all. Eventually, the constant porting effort becomes too expensive in money and/or time and it gets killed or key features get killed. One set of source that works everywhere automatically is the goal we should be going for, not a quick hack port.
-- soldack
The wxWindows interface is closer to MFC than GTK and on most Unix systems it uses GTK. Perhaps it would save some time instead of starting from scratch.
When I said, "Writing things the correct way the first time," I was talking handling porting code and the commenting out code issue. Here you have a simple decision that will effect coding efforts many months or years into the future.
I agree that in general writing things the correct way is not easy and nobody is perfect should expect perfection. The difference is that here you have a single decision where you know that one way you couldn't get away with on the job or in school. In this case you just know that by simply commenting out code you are taking the easy way out. What kind of grade/raise would you get for that? What would your coworkers think when they get a bug in this comment trail?
On your personal notes....
Actually, I gave free CS and math help in college and happily give directions when I know them. At work I write requirement and functional specifications and I write code. What is wrong with specifications? Should we just give up on documenting anything? I guess we could write even more unreadable, unmaintainable code and provide instant job security. Nah, I think I will stick to making my fellow programmers' lives easier so they will do the same for me.
-- soldack
I can't blame him for wanting to see what's a comment and what's not when he has no control over what became a comment in the first place. Although I must agree with you about cleaning out those damn comments in the code you're writing.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
You're going from very specific libraries for a particular OS to something a little more vague. Also, the widgets and window designs don't necessarily have a one-to-one ratio.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
I'm about to take my MCSD on Visual C++... coming from a previous UNIX Background and working on integrating both platforms, i'd like to share my thoughts:
/usr/local/g++/bin/CORBAimport as a handler for #import directives. It could be useful for KDE's moc, for instance. :)
:]
First: MFC was portable. Runs on everything NT runs on... runs on CE (albeit limited) and runs on MAC (they even ported OLE to Mac, way before they decided to split up ole and bring up COM)... Its portability doesn depends upon the compiler, as microsoft pointed out on a MSDN article about IE5 on Slowlaris commenting their experience with MainWin. Their main dependence comes not from the compiler: MFC apps can compile under Borland, Watcom, Symantec... Under the language aspects, they're fairly traditional, implementing their own exception system (using setjmp/longjmp). Its not bad.
The problem with MFC is that people haven't been separating its goal: its for UI... your UI design shouldn't model your overall (logical?) application design. A good point i always make is, when developing an MFC based app, to design its IDL (for OLE/COM Automation with some help of ATL) and _THEN_, design its interface. The UI becomes an layer for the automation. It helped me implement systems which let me port easily, using CORBA instead of OLE.
And as for language extensions, they're mostly COM-related: #import, runtime classes (not pertinent to MFC neither ATL, but part of MSVCRT.dll), and __declspec/__uuidof, for CLSID/IID tagging within the object code. Btw, it would be neat if g++ could implement modular preprocessors on it, letting me choose (this is an hypothesis)
the fine print: god, if you want your shitty level editor to be portable, start using it with JAVA. Its performance will be poor, but it will run. you sucker.
What in the world are you thinking?
Of course you can write your own version of the basic data structures and algorithms found in the STL! You could write your own GUI toolkit--but why would you want to, when their are dozens of quality, well-maintained efforts that do it for you?? You don't use the STL to get new functionality (necessarily)--you use it to achieve interoperability, modularity and reusability. If you're not using it, your code will be left behind.
Let's try not to let fact interfere with our speculation here, OK?
We got bitten by an extension the other day: exception specifications. According to Stroustrup, if a function specifies what exceptions it throws, and another exception is thrown, the runtime should call unexpected(), whose default behaviour is to call terminate(). Of course, MSVC doesn't enforce this, so a program that we've just ported to the Mac keeps unexpectedly terminating (it was written by a programmer who only knew MSVC, and so hadn't experienced true ANSI C++ behaviour).
...
Then of course there is the irritating "feature" where variables aren't scoped properly:
for (int i = 0; i < 4; i++)
{
}
// i should be out of scope, but this works in MSVC
i++;
Comment removed based on user account deletion
Well - I've been programming with wxWindows (available at http://www.wxwindows.org) - And i think of it as a perfect replacement for MFC, if you think about serious cross-platform coding. The technology is still quite new, but there is virtually nothing that cannot be done with it at the moment.
"I've never seen any performance guarantees for the STL. AFAIK any implementation is free to implement the standard in any way they choose"
;-)
The STL specifies performance characteristics throughout. The STL can be implemented any way the developers' want, as long as it conforms to these performance metrics.
"Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's?"
I didn't make the original comment, so I can't speak for the poster, but I'd put my money on any one of the major STL implementations (rather than your homebrew classes) if I had to bet on quality of code. Nothing personal--I'm sure you're a very capable coder, but you still can't compete with a team of dedicated developers
"STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL."
But the STL is part of the standard. There are free, high-quality implementations available for nearly every platform that has a compiler. If a professional programmer doesn't understand the STL now, he/she better learn it soon, because it *is* the standard. Even Rogue Wave knows this--lately they've been marketing their libs as add-ons to the STL.
"STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either.
You were responding to me--so I'll reply here. Saying that STL adoption isn't widespread isn't an excuse for not using it. It's new. It isn't surprising that a lot of older code bases don't use it (yet). That doesn't matter--if new code is being written in C++ today, it should be using the STL. If you have specific interface conflicts that have to be resolved, that's one thing. If you are resistant to using it simply because no one else is--that's just dumb. Sooner or later, all those old libraries will be using the STL, and you'll have to change your code anyway--why not write to the STL today and save some trouble in the long run?
Let's try not to let fact interfere with our speculation here, OK?
Large amounts of commented out code make programs unreadable.
Comments should be used for comments. Some text explaining code.
Is it just me, but does the phrase `Why don't explain what the code you commented out originally did and why you needed to modify it' seem completely and utterely bleeding obvious?
It's been over a year since I used Visual C++, and even then it was 5.0 (6.0 was out but I admit that I never used it). At the point, I'm not aware of any extensions to the language that couldn't be easily disabled with a #define. All such extensions were fully compliant with ANSI C++, starting with double-underscore (I think it was two).
Are there other less compatible changes? I know this was a real problem with Borlands OWL, but I never had a problem with Visual C++.
David Corbin Promote Freedom - American Liberty Foundation
I suppose you could say the same thing about Visual Basic. AAaaaH, HA-HA HA-HA HA-HA HA!
Brick wall it would be, and that's his point.
Friends don't help friends install M$ junk.
You don't know what you're talking about you foolish person. Perhaps you've heard of KDE? Version 2 is due out in about 10 days time and includes a Samba share browser as part of it's file manager, and guess what? KDE 2 has been usable for a couple of months now. And if you say 'why do I have to use beta software', just because MS releases something doesn't mean it's ready or it works as specified, at least on Linux, people are honest about when a piece of software reaches a final version, because it's driven by coders, not by internal and external political appearance.
Um, duh, are there any other freely available, widely used compilers? Remember, Linux stuff needs to be free/GPL/whatever, and prudence demands that the compiler be ubiquitous.
I want to delete my account but Slashdot doesn't allow it.
Where do you work?
If you're in or around the Bay Area, you should have no trouble finding yourself another job with more flexability.
I work at MontaVista. While when we write code for customers it has to be in a language and using libraries they support (and in embedded-space that can be quite restricting), testing tools or anything else for internal use are up to the person writing them.
The last place I worked before that, I did system administration and support for a small business. As long as the server stayed up and Did What It Was Supposed To, nobody cared how.
The place before that wanted C++ -- even when the job was better suited to Python or Perl. I'd prototype a scripted version, give it to them far ahead of deadline, and then have a C++ port ready by the final deadline. I still think doing this helped me get done sooner -- and they were really in no condition to complain. I'd be unsurprised if (had I stayed there longer) they'd have eventually just accepted the scripts.
In short, there are lots of Real World places where it's your call. Go find one. You'll be happier.
As for you saying that the only that daemons and tty clients should be in textmode, that's just foolish. For one thing, a graphical subsystem uses up more resources than just the console, so it is an advantage to have many tools in the console. There simply isn't as much power in a GUI, for instance, in console, you can string a huge amount of pipes and conditionary executions such as with &&. As for saying the GUI is easier and faster, that is only the case in some instances for some things. Obviously, with graphics editing, a GUI is a much better solution. But, I at least, find it takes more time to keep double-clicking (or even single-clicking) on however many directories to get to just one, then right-clicking and going to Copy, then navigating around some more to find the next directory and then right-clicking and going to Paste. It's much faster to just type, say: cp /var/lib/apache/share/htdocs/manual/images ~/my_files . The power and in many cases, the ease and speed, of the console are not matched by a GUI.
"The price of freedom is eternal vigilance." - Thomas Jefferson
"The reason for this is to give a visual hint as to what is a comment and what is actual code. The rest of the syntax highlighting is less important in this case. While porting, never delete a line of code. Comment it out and make your changes below it. If you need to, comment out whole functions. You are going to find that having an immediate reference to the original code is immensely helpful, but all that text can get very confusing. Syntax highlighting makes everything much easier. "
/* */ blocks.
I couldn't disagree more. Large amounts of commented out code make programs unreadable. Why was it commented out? Was it test code? An older version? Something that wouldn't compile but needs to be fixed? Who knows...often not even the orignal commenter after a few months. Don't think that you will go back in fix it because you will not. There is almost never time to fix badly written code that seems to work because there is always new code to write. You will net get time to look at it again until a bug pops up. And then you will be left wondering what in the world was in that commented code. Writing things the correct way the first time makes life much easier.
Comments should be used for comments. Some text explaining code. They should be used for turning code on and off (use precompiler statments, much more flexible) and they should not be used to save old code. Try using a source repository that has version diff support like cvs. This is a much cleaner way to see what you had before without leaving your old code lying around in massive
As for comment syntax highlighting being the only usefull part of syntax highlighting, I have to disagree again. I like to see different parts of the lanugages syntax in different colors. Hence the name "syntax" highlighting, not comment highlighting.
-- soldack
If I recall, Carmack was thinking about making id tools Java-based during Q3's initial development. Although that never panned out, work is being done (by TTimo's team at QERadiant.com) to make the existing Q3 tools cross-platform with a common code-base by porting the Linux GTKRadiant port Loki developed back to Win32 (they just recently made their first Alpha release).
Incidentally, this will all be moot with the next Doom title as far as id engines go, as the rendering/level architecture will allow the editor to be built into the game executable.
Still, it'd be nice if GTK+, QT, or some other cross-platform widget lib gained acceptance among developers for home-grown utilities. Hell, it'd be even better if applications in general used cross-platform libs more often (how difficult are Win32-OSX ports now?), but that's probably years away at best.
:wq
But it all goes back to Microsoft's attempt to shut everybody out of Windows. Just like they did to J++, they have made the MFC and Visual C++ GUI classes so tied to Windows, its almost impossible to "digest" the code without 2 or 3 MFC and Windows API manuals. Thats why I have been programming C++ on UNIX for 5 years, and haven't written a line of Visual C++. I looked at doing a project in Visual C++ once, and soon decided that rather than waste 2 years of my life learning Windows API and MFC, I would just right the GUI portion in JAVA and do the back-end stuff in ANSI C++ on a UNIX. Got it done in a couple months. :)
Too bad the gaming industry can't come up with a standard, portable library tool-kit that they share and use for mutiple platforms. They would learn allot from taking an open-source approach. However, most of them guard their tools and programming methods so jealously, this would never happen.
Maybe there is an alternate universe where there is such a thing. ;)
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I am not sure what kind of C++ code is used to program the games, but g++ 2.95.2 chokes on the OSE library (both under Linux and Solaris).
Egcs 1.1.2 (aka 2.91.66) is a more stable choice, IMHO.
Also, STL from SGI is now up to version 3.3 - yay!
wxWindows still has some rough spots, but then so do almost all other toolkits. If you don't need quite as much functionality and can do without native LAF, FLTK is also pretty good and much smaller.
MFC Source is completely visible and I believe it's intended to be portable. It's just another app framework dude. Just happens to be MS's. I think that's why your reaction comes so vehement yet uninformed.
While there are many UI elements in MFC but there are a bunch of other objects that have nothing to do with the UI. In fact tyou can avoid STL completely. I'm not saying you necessarily always want to do that but you can if you want. Things like:
- CException
- CFile
- CArray
- CObArray
- CPtrArray
- CList
- CString
- CMap
There are others. I've written quite a few command-line win32 programs that use MFC objects and have no GUI whatsoever. Very handy for iterating objects in a general sense. You can use STL if you like but you don't have to.WINE derived apps are slower than many native ones. Why? Because it's translating things over to native behaviors. It's still a translation layer, albeit a thin one.
Which would I rather have? If I had a choice of no app or a WINE app? Dumb question. If I had the choice of a native Qt, Fltk, Wx, JX, GTK+, etc. app versus a WINE app? Dumb question, again- native is better than non-native.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
"GTK isn't OO either - it's a C API."
Right on, brother-man. =)
Too many people think that the well-defined use of data structures constitutes OO programming--GTK+ is a fine example of this, IMO.
Yes, GTK+ makes heavy use of structs and unions and function pointers to acheive a sort of object-oriented feel, but, in the end, it is still a collection of C functions that just happen to pass around lots of structs and unions and function pointers.
Writing true OO code requires a fundamental shift in the way one thinks about software. In OO, you can't fall back on functions and procedures--you have to figure out what object a given procedure should be attached to, or failing that, how you can implement the functionality as an object in itself. OO coding is a philosophy--so much so that I personally find it difficult to switch between C and C++ when I'm called upon to do so--even though the languages are syntactically very similar.
There's a lot to learn to write good OO code, which is why most programmers can't do it yet. And those who would say that GTK+ is OO programming fall into this category, IMNSHO.
However, MFC is OO--however badly designed it may be. Yes, MFC is littered with hacks and questionable design decisions (see Message Map discussions elsewhere), but the fact remains that you can create an MFC app without using a single C-style function You couldn't hope to do this in something like GTK+ (but maybe in GTK--).
Let's try not to let fact interfere with our speculation here, OK?
Speed is obtained by doing it for yourself down to the barest Win32 API layers. Power is obtained the same way. MFC buys one thing- laziness. It's easy to bang out a UI for an office/buisness app with it. Try to do something fancy with it- forget it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Kind of an odd little paper. Sounds more like he's venting at frustration of explaining to a group of linux porters the basics of working in a group -- CVS, committing frequently, liberal use of assertions, commenting out chucks of code rather than deleting.
Still enjoyable. I would have preferred something more along the lines of comparing media API's between the two platforms, and the workarounds the gaming community is implementing to get past platform differences.
I am often saddened that Andre LaMothe decided to "go windows" rather than move his gaming expertise into a more neutral OpenGL and Linux direction. I found his book exciting and style easy to read.
It would be so cool to see someone compare and contrast the methods in "Black Art of 3D Game Programming (LaMothe)", essentially a DOS book, into something modern and Linux-based.
Obviously, I'm fairly new at all this, because it looks like OpenGL makes a lot of the code in the "Black Art" book redundant. Nevertheless, it would be an interesting treatise on game programming to see all the 2D, 3D sound stuff in that book re-written for OGL/Linux.
gcc : Yes, we have problems, too...yet it does appear to be improving. Some of the templating and inlining seems really, really broken.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
I think that it would help if someone here really knew MFC. I can full-heartedly say that I don't know it, though I do know Windows API. Any way, MFC may not be compared to GTK+, since GTK+ is C-function-oriented (like Windows API), and MFC is completely C++ OO. So it's equivalent to Gtk--, and nothing else.