wxWindows vs. MFC 103
EvanED queries: I'm going to devoloping a chess program, and was until a couple days ago planning to do it in MFC. But then I ran across wxWindows. I think it would be cool if it were able to run under Linux. (At the moment, I do not have Linux on any computer but will as soon as I get my own machine.) Do the benefits of supposed cross-platformness outweigh the drawbacks of having to learn a new system and not having all the (incredibly wonderful) automatic code generation features Visual C++ provides for MFC programs? Or would it perhaps be better to write it in MFC since I am reasonably familiar with it then port it to wxWindows?"
pragmatic answers (Score:5, Insightful)
This is a question you can only answer yourself. It's always more work to take more than one platform into consideration, and wxWindows is no panacea in this regard. Only bother with cross platform coding if you really indend for the code to be run across platforms. That said, wxWindows is nicer to use than MFC, although for a Windows-based chess program, I doubt you'll be able to avoid MFC entirely. MFC just does more than wxWindows.
This autogenerated code is so awful, I used to create it just to frighten people: "Look how many lines of code it takes for this dialog box!! Pay me more!!" MFC is the single largest reason I've given up on Windows programming permanently (Winsock is a close second). Since this is clearly a learning experience for you (right?), then go ahead, play with MFC. Nothing teaches like pain. But be warned, MFC plus Visual C++ can make you hate real C++ by warping your mind. __int32 indeed.
This is the path of greatest work and quite likely greatest learning. If you'd like to pursue the path of least pain to produce a truly cross-platform GUI app, I suggest, from experience, TrollTech's QT [trolltech.com].Re:Qt (Score:2, Insightful)
The main advantage wxWindows has over Qt is that it has truely native look and feel (LNF). Try running your Qt program under Windows XP and compare it with a wxWindows one -- which one looks really native? Personal preferences aside (i.e. forgetting that I hate XP LNF), wxWindows clearly fullfills the goal of allowing you to create native looking applications better. The same goes for wxGTK port: Qt apps will never use yyour current GTK+ theme, but wxGTK ones will.
Further, why ask "why not just use Qt"? Why not rather ask "why use a proprietary and closed (in the sense that you can't modify it nor participate in its development) library instead of completely free, open and at least in some ways superior one"?
Re:pragmatic answers (Score:2, Insightful)
I will admit it's been a while since I've used MFC. However, my experience predates Windows by a fair amount, so my appraisal of MFC isn't based so much on an ignorance of the windows API but on knowledge of many GUI api's in general. Having used Iris, OpenStep and others before Win32, I can look at the MFC code generated by the wizards (and by myself) and conclude it's garbage. I've created comparable apps, in other frameworks, and MFC has for me always been the most painful to use. Borland OWL comes in a close second. Motif gets third.
The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks. I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about. I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.
Finally, porting fromanything to anything is by definition more work that simply writing that one thing once. If you mean for your code to run on multiple platforms, start from scratch coding using tools intended to work on multiple platforms. If you want to write windows apps, use .NET, cuz' MFC is dead don't ya' know.
This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.
The paralyzing FEAR of wrong choices (Score:2, Insightful)
Programmers are easily seduced into creating code to cover all the possibilities of the world. It's more comfortable because;
a) you avoid doing a lot of the design choices that are involved in actually finishing and shipping applications, and;
b) you feel like you're doing "good work" and reducing the risks by covering all the possible cases because you don't really know what the design needs
You're doing good work all the time, you can't possibly fail, right? Wrong! Many projects die well before finishing the library, the engine or the platform that was supposed to be the carrying structure of the application.
Letting technology desires drive development you can continue your good work for the rest of your natural life without ever having to face the fear of actually completing a project.
In the real world, porting software is actually often left for the interns and/or outsourced to other companies. Porting solid code after it's done is not the problem that kills projects. Most projects never live long enough.
Here is a radical idea: design and develop the application first, worry about porting it later. Write solid code for any platform of your choice, it will only take you a fraction of the time to re-do your UI for other platforms you plan to target. If you want to finish, force yourself to only write code that takes the application forward by concrete, measurable steps.
Work with a product designer who knows what they need to accomplish and how to get there.
Conquer your fear of making choices and finishing applications, only shipped products contribute to your track record of greatness.
Re:Clarifications on VC++, Qt (Score:3, Insightful)
Learning MFC is learning Microsoft Macro(TM). It's the most shallow and unambitious class framework I've ever seen, almost to the point of making you wonder why they even bothered with C++ (the templates I guess). Doing anything remotely interesting with the GUI requires falling back to messages and win32 calls. If you look at serious class frameworks (Borland's original OWL, then VCL, Java,
Software Development for the World (Score:5, Insightful)
Why limit yourself to two platforms? Write the back-end of your chess program so that it communicates with a front-end client by passing certain messages (perhaps in XML format). You might even make the message specifications public so that others could write clients for your chess engine.
The back-end only needs to concern itself with a virtualized game, not worrying about the details of how to go about putting a picture on the screen or interacting with the user.
This also allows the engine to apply 99.99% of its compute cycles toward planning its next move. It won't waste any time on mouse movement or other windowing events. Only when it receives a message will it be interrupted from "thinking."
By separating the core part from the presentation part, it allows you to use your chess engine with multiple front-ends. You might write one front end for Windows, one for Linux, one for Mac, and another with a web interface. The front end only has to know how to interact with the user and send and receive messages to the chess engine.
You could even expand the engine to handle multiple games at once. That extra feature should be easy to implement if the back-end and front-end are separated. It just means keeping track of more than one game and communicating with more than one client. You could be playing against it on your Windows box while someone else is playing over the web. Or perhaps you could set it up so that another human could play instead of the computer.
If you write your back-end using reasonable standards, then you should be able to easily port your chess engine to another system since you don't have to worry about different windowing systems.
Just a thought