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
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
"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?
...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
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".
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
#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.
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
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...
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!
But user interface stuff is exactly the problem. Yes, you *can* write a win32 app with Visual C++ without using the MFC, but it is akin to writing an X program with raw Xlib calls. And as regard to portability, I doubt most companies give a damn -- that's why there are companies like Loki which buy the rights to do the Linux ports -- the original companies aren't interested.
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.
Right, but why not use something like wxWindows? You can make the case that this would definately leverage your investment in a framework across different platforms. MFC is not an issue then.
Because here in the real world, programmers don't make those types of decisions. If you have a choice as to which language/library to use consider yourself lucky. Hell, I'd be happy if I had a choice as to which indention style I used.
That really depends on how you measure success. If it means a lot of people using and contributing to the software, then it's generally very successful. Iff it's under a free license, and you have sufficient people skills to manage a project. Otherwise it's like pissing in Niagra Falls.
I've noticed. It didn't used to be that way, though. I have the nagging feeling that Slashdot's done for the Free Software userbase what AOL has done for the Internet's userbase.
DNA just wants to be free...
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.
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...
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
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.
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.
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.
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.)
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.
--
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...)
Fight Spammers!
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?
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
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.
While your're right on the first two points, you're wrong about COM. COM is terribly usefull, when used appropriatly (and as a replacement for C++ objects, which MS is touting them to be isn't one of the correct ways.) COM wasn't designed to be a GP object model. It wasn't designed to be subclassed. What is was designed to do was make major components of applications easily replacable and upgradable. That is a genuinely good idea and Mozilla uses it to (in the form of XPCom.) DirectX is the perfect example. It is stupid to complain why you can subclass from IDirect3DDevice7 because that's not what it was designed to do. Its like asking why you can't subclass from the C functions in OS.h (for non-Be users, that implements a lot of kernel level C interface for BeOS) What COM does in this case is make DirectX easily upgradable. So far, DirectX has gone through 5 (going on 6) revisions. It has been totally overhauled more than once, and has gone from a POS to a super-sexy API (if you can understand it.) One thing that made it possible was COM. By tightly defining the interface between components, DirectX has been able to stay more or less backwards compatible without resorting to multiple libraries for the different versions (one major thing that pisses me off, that kdelibs-1.x and kdelibs 2.x aren't compatible) This idea would be great used in a lot of other places. For example, it could be used to define the app->Desktop environment protocol. That way, you could totally replace KDE with GNOME, and all your apps would continue to work (as long as both GNOME and KDE strictly followed the protocol.) Each would still be seperate projects, and still having vastly different strenghts and weaknesses, but we wouldn't have to have both installed. (Think of it as TCP/IP for the local system.) COM isn't a very big hack at all. You can duplicate much of its functionality (for in-proc servers) through dynamically loadable libraries (add-ons for those Be folks.) You create an abstract class, and use that in the client program. Then you have a class implement that interface, and compile it into a add-on. You use some kind of mechanism to give an app the name of a particular add-ons, and then import a function to pass an instance of the implementing class to the calling program. Voila, everything works quite well. Of course, if you use the other 90% of the COM/OLE API, then god help you. However, if you do that, you get what you deserve.
A deep unwavering belief is a sure sign you're missing something...
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
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.
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 duh! Out of 250-something classes in MFC, I would estimate some 200 are UI related - directly or indirectly (for instance OLE related classes etc.) MFC isn't perfect and it's not as well designed as say Java's Swing, but it's still a pretty good class library that simplifies Windows coding a great deal.
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
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.
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?
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.
"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
Also, MFC provides quite a good object-model that makes sense if you have experience with Win32. Most people complaining that MFC sucks don't know anything about Win32 and expect MFC to replace their knowledge. That's not true, it's just a framework for people that would rather write GUI apps with an OO approach (and IMHO, OO is extremely well-suited for GUIs.)
MFC does have some bad sides: lots of messy macros that are horrible when you're debugging and trying to understand what's happening and an Application Wizard that generates all kinds of garbage in the middle of your code like message maps. But you don't have to use the macros and it's even very simple to write an application without using the Wizard to generate the framework.
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"
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.
Gtk for windows is available at http://user.sgic.fi/~tml/gimp/win32/
It's still a little rough around the edges, but nice to program (a _lot_ nicer than MFC or the raw win32 API).