Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Qt vs MFC 126

Posted by timothy from the they're-sure-spelled-differently dept.
Philippe Fremy writes: "I have just published and translated into English a comparison between Qt programming and MFC programming, which was written by Pascal Audoux (a fellow coworker). I am interested in feedback and would love to add quotes from developers that have used both toolkits." Here is the English version ("Qt vs MFC") as well as the French one ("Qt contre MFC").
This discussion has been archived. No new comments can be posted.

Qt vs MFC More

Qt vs MFC

Comments Filter:
  • Well, that's obvious. From the article:

    The conclusion drawn from our personal experience is obvious. Qt is far better than MFC. You'll produce better programs with less hassle.

    I do agree though. ;-)
    • Qt is far better than MFC. You'll produce better programs with less hassle.

      Very true. Literally within an hour or two, by following TrollTech's tutorial, a person can write and understand working GUI applications. One of Qt's strengths (and a tribute to its design) is how its learning curve is really quite low.
      • One of Qt's strengths (and a tribute to its design) is how its learning curve is really quite low.

        For simple applications, MFC's learning curve is also low - the wizard will generate all the glue code and provide // TODO comments where you plumb in your own code. You can have a simple, fucntional MFC-dialog-application up and running very easily, invoking the MFC API only a few times yourself.

        For an experienced Win32 programmer, MFC's learning curve is pretty much zero (flat?).
        • ...the wizard will generate all the glue code...

          Qt doesn't need wizards, because the API really is quite clean. A person who has never programmed a graphical interface but knows C++ is good to go. The only real impurity in Qt is that the moc preprocessor needs to run as an extra step in the build. However, moc enables the rather simple signal and slot mechanism, which is intuitive and serves its purpose very well.
  • In Qt, objects are always open. There is not "Create()" function. What is when opening fails in the contsructor, does Qt use exceptions? If yes, then correct Qt code has to use "try {...}" on every creation of widgets. In other toolkits, "Create()" returns a BOOL, and you must use "if (Create()) {...}". I think the KDE developers admitted they didn't like exceptions. There's no problem in using exception, but if you write a Qt program, and derive classes from Qt classes, your classes will also throw exceptions in their constructor. Not everyone writes their code like that, and proting existing C++ apps may be difficult for that reason. The other way around, if a library uses "Create()", then wrapping around your own code which calls Create() in the constructor is not hard.
    • Ummm... no. Qt may or may not report errors via C++'s exception mechanism, I don't know. But insinuating that exceptions are the *only* way to report errors encountered during a ctor is patently false. For a counter-example, one need look no further than the standard IOStream library:

      #include <iostream>
      #include <fstream>
      #include <cstdlib>

      int main() {
      std::ifstream file("file.txt");
      if(!file) { // look ma, no try block!
      std::cerr << "file.txt could not be opened for reading.\n";
      return EXIT_FAILURE;
      }
      return 0;
      }
      • So what happens if the ifstream can't be created on the stack because file.txt is too large? oh...ifstream allocates memory in its constructor to handle that problem. What happens if you are in a low memory condition and the memory can't be allocated?

        Exceptions aren't the only way to report errors. Return values from a function is another way. Also using a global error object is another. Problem is in your example the program has no way to know why ifstream couldn't be created. Also ifstream has no way to communicate that to the program except through exceptions. That is because it uses its constructor to do it initialization. Since there are no exception handlers wrapping the creation of ifstream an exception would stop all execution of this program and the OS would provide a nice little popup to the user that makes no sense (on windows at least).

        So next time...think about the code you are writting and why functions like Create() exist.
        • If ::new fails then it will throw, sure. But the object is free to catch std::bad_alloc inside the ctor and transpose it onto some other error-reporting schema. Just because something *in* the ctor throws, doesn't mean that the ctor has to propogate the exception.

          As far as ifstream is concerned, you can't tell *why* the file couldn't be opened because ifstream is abstracted that way. You could easily have some sort of "error state" (similar to badbit, eofbit, and failbit) which can be reported to the client only when the client asks for it. Simplest way I can think of to do that is with a get_last_error() member function that simply returns the error code of the last operation the object performed.

          Sure, exceptions can be helpful in RAII, but they are by no means required by it. To assume so is not only incorrect, it diminishes C++'s lack of paradigm bias.

          The only time I can think of when you're *forced* to propogate exceptions is when you have a polymorphic class whose base class's ctor throws. But then, you made a design decision to inherit from a class that throws.
          • The only time I can think of when you're *forced* to propogate exceptions is when you have a polymorphic class whose base class's ctor throws.

            Any subobject (base class or data member) that throws during construction will result in the object itself failing with an exception. You can wrap the c-tor's initialiser list in a function try-block if your compiler supports it, but that only allows you to change the type of exception thrown, not the fact that some exception is thrown. If you think about it, that's the only model that makes sense, and it's also very clean and tidy.

            • Yes, that's the only way the object model can make sense *if you're containing actual objects*. You can easily get around that by changing the contained object(s) to a contained pointer to object. Same goes for private inheritance: change it to a contained pointer to object. If all your after is interface inheritance w/o polymorphism, just use a contained pointer plus forwarding functions. Like I said before, the only time you're *forced* to propogate exceptions from a ctor is when a polymorphic base class's ctor throws.

              • I think what you're trying to say is that if you don't want to allow a constructor to fail, you can change your design so that you can trap the exception that would be thrown by a base class or data member under normal circumstances. That's not what you actually said, though.

                Of course, whether you want to have a design that carefully works around a system that's there for your own good is another question. Most of the time I've seen designs that went out of their way to ignore exceptions in a system that used them, the design was broken. Two-stage construction with Create() and Destroy() methods is a Bad Thing(TM) under almost all circumstances, and is responsible for more programming bugs in C++ than almost anything else I've come across (apart from naff use of pointers and arrays when smart pointers and container classes were the right tools for the job, of course).

                • Sort of, but not quite. It's not a *design* change, it's an *implementation* change. Big difference. My only exception (polymorphic base class ctor throws) is the only situation where avoiding a throw in the ctor would actually require a design change.

                  I think we're pretty much in agreement, though. Don't know why anyone would go through all that trouble just to avoid a try block anyway.
  • ...would be nice too since wxWindows is growing in popularity. Any one have experience using both wxWindows and MFC? Maybe a comparison between wxWindows and QT would be useful and interesting as well..

    Perhaps the most useful of all would be a comprehensive somparison of all the various toolkits/libraries.

  • I've been doing lots of Qt, GTK and Java programming, a few months ago I needed to start hacking on a MFC project. I tell you, never ever again. I'm now having a cronic headace, thanks alot MS. And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions, I'm sure I encountered 20 different typedef s for "unsigned int" just browsing through some MSDN pages. Not to mention the joy of unwinding a structure so you can get to business. Theres a structuer with a structure, member, with a member,with... And they each have members of type unsigned int, WORD, p_WORD, uint32. If somone know how to make apis and code even more unreadable I'm sure there is an open job somewhere near Redmond.
    • And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions...

      Could it be to support more than a single machine architecture? Windows NT used to run on Alpha boxes and now, the move to IA-64 means that an unsigned int is going to change size. They typedef everything to ensure that no matter what platform they move to, the framework doesn't require major changes.
      • Strange I dont encounter this that much in the posix world, which runs everywhere, atleast not within the sae library/API. I rather suspect their mess comes from the fact that they have to keep binary compability. And that MFC mostly a wrapper a round the Win32 API, to which they change their internals with virtually every build(or so it seems). Its though a pretty bad excuse, the thing is to do it right from the beginning.
        • Actually, a lot of the mess in MFC is not due to the changing Win32 API, but left over from the switch from 16-bit Windows (i.e. 3.11) to 32-bit Windows (95/NT & later).

          It's this backwards compatablity that hampered MFC through too many years. Unfortunately, the only way to get rid of it now would be to start over (which will never happen now that .net is MS's future).
          • I actually see the WinForms aspect of .Net as a starting over point for programmers on the Windows platform. Microsoft has known for a while that the old API was showing it's age. .Net is less about developing a new technology, but refactoring the existing technologies and products for stability, security, performance, and all other sorts of good stuff.
      • And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions...

        Could it be to support more than a single machine architecture?

        I think also to support both 16-bit Windows and Win32 together, although that's more relevant for the base windows headers than MFC.

        I don't mind a little opacity on the OS interface. And you often gain meaningful type names too.

        (There are a number of examples on Unix, too: e.g. uid_t, pthread_t, etc. But certainly not to the same degree.)

        • uid_t and pthread_t are useful - they are the types used to hold a user ID or a thread ID. They can and do vary between implementations. Likewise types such as uint32_t and int_least16_t (from the C99 standard) are useful.

          The WORD and DWORD types do not provide an abstraction and do not obviously have any particular numeric properties. I happen to know that the names WORD and DWORD come from x86 assembler and are signed 16-bit and 32-bit quantities, but a portable API should be using names like INT16 and INT32 for such types instead. Some of the other types are more reasonable, but the API is not that consistent.

          All the pointer-to typedefs should be got rid of; they may have been somewhat useful under Win16 but are no longer relevant. UINT and ULONG are likewise fairly pointless.

          In a few places the Win32 API could do with more use of typedefs, for example for process and thread IDs (currently DWORDs).

  • This is a bit of a strange review:

    I always thought that comparisons had to be done with some kind of objectivity, if only for the purpose of decency... Apparantly this is not the case: MFC was produced by hordes of rabid monkees while God himself came down and Created Qt.
    Even not a C/C++ developer myself, I don't see a lot of proof / illustration to the MFC side and way too much positive adjectives on the Qt side: "genious", "excellent", ...

    The best one was probably:
    "One of the stated goal of Trolltech is "The product and the documentation should be so good that no support is needed".
    QED...
    Qué?

  • Good conclusion, poor article (Score:5, Insightful)

    by uradu ( 10768 ) on Monday July 22, 2002 @10:13AM (#3929889)
    While I wholehartedly agree with the conclusion, I must say that the article is a mess and feels like it was written by a 16-year old. It's barely comparative, sticking to the format that feature X is messy in MFC and much easier in Qt, and here's an example of just how easy. He doesn't give any MFC code examples, mainly limiting himself to explaining the horrors of Unicode and resources. An objective reader could hardly take this for a serious comparison of the two frameworks.

    Besides, it's really comparing apples and oranges. Anyone who's used the MFC at all knows that it's hardly OO. A much fairer comparison would be that of Qt to Borland's VCL. In many respects they're very, very similar, but it seems that the nod of more consistent OO design would go to the VCL. I base this mainly on the event-handling semantics of both toolkits. While Qt falls back to straight C (or possibly even a macro? shudder!) for connecting an event handler to a component, the VCL stays faithfully OO, implementing event handlers as method pointers (exposed as properties) on components.

    Continuing the example used in the article, Qt reads:

    connect( button, SIGNAL( clicked() ), SLOT( action() ) );

    while the VCL would read:

    button.OnClick = action;

    Anyway, as I said, while I support the conclusion of the article, based on its lack of maturity I wouldn't use it to try to convert existing MFC programmers.
    • While Qt falls back to straight C (or possibly even a macro? shudder!) for connecting an event handler to a component, the VCL stays faithfully OO, implementing event handlers as method pointers (exposed as properties) on components.

      There are some comments in the Qt documentation [trolltech.com] why the approach isn't always strictly OO.

      while the VCL would read:
      button.OnClick = action;

      Just curious: if button.OnClick and action are both method pointers, how can you have more than one action in response to a click?

      • > Just curious: if button.OnClick and action are both method pointers,
        > how can you have more than one action in response to a click?

        Well, you're right, you couldn't in the current implementation. The simple method pointers on the components would have to be replaced by some sort of object with Add and Remove methods of its own, which would then insert the event handler assigned into some notification data structure. Basically you'd be "OO-fying" what connect() does in Qt. It would likely have more overhead than the Qt approach, so it's a matter of what you value more, OO-ness or performance.
        • Well, you're right, you couldn't in the current implementation. The simple method pointers on the components would have to be replaced by some sort of object with Add and Remove methods of its own, which would then insert the event handler assigned into some notification data structure
          Actually, you could (and they might) handle this by overloading the assignment operator (assuming VCL is in C++, I'm not familiar with it) so that it did in fact do an Add(). There are issues with this, and it would need to be fleshed out (and you'd have to figure out how to make a semantically similar Remove(), which is problematic), but it's possible. Mostly I'm arguing for pedantry's sake.
          • > Actually, you could (and they might) handle this by overloading the
            > assignment operator (assuming VCL is in C++ [..])

            It isn't, though, it's in Object Pascal, which doesn't support operator overloading. You could still do it by changing the event handler method pointers to pointers to a singleton object that did the same work as connect() via an Add() method, without incurring any memory overhead per event handler per component.

            > you'd have to figure out how to make a semantically similar Remove()

            Well, in C++ you could simply overload the following operators:

            += : add this event handler
            -= : remove this event handler
            = : clear event handlers, then add this one

            I believe that's the mechanism they're using in C# with delegates (except maybe for the third one).
      • You could make a MultiAction class that you can Add and Remove any number of actions to/from.

        Granted this would be nicer integrated directly into the framework, but you can still do it yourself if necessary.
    • Actually the CLX library, used in the lasts Delphi and Kylix and CBuilder versions, (very similar to the VCL) is based in the Qt library. If you code for CLX in Delphi you are coding for windows AND Linux, thanks to Qt.
      You can't link many events handlers to a single event, but you can link a single handle to many events, if they have the same event type.
      When do you need to link an event to many handles? please give an example.
      • > Actually the CLX library [...] is based in the Qt library.

        True, but that should be thought of as an implementation detail. You code to the CLX, not to Qt. Theoretically Borland could in the future rewrite the CLX on each platform straight to the metal without using Qt, and your programs should still compile. In practice they probably did surface some Qt here and there, maybe data structures taken as parameters of some methods, same as they did with win32 in the VCL.
    • Anyway, as I said, while I support the conclusion of the article, based on its lack of maturity I wouldn't use it to try to convert existing MFC programmers.
      As an MFC programmer who has discovered the glory of WinForms, lemme tell you: if we're not getting paid for it, we don't need any convincing to move from MFC to greener pastures.
    • > A much fairer comparison would be that of Qt to
      > Borland's VCL

      I would actually be interested in seeing a good comparison of Qt vs GTK vs VCL. I used to be a VCL programmer (C++Builder and Delphi) so would be interested in seeing how they compare.

      Cheers,

      sd4l

  • Advocacy, we never knew thee. (Score:3, Insightful)

    by Zapman ( 2662 ) on Monday July 22, 2002 @10:15AM (#3929911)

    This guy doesn't seem to understand much of what he's talking about.

    The most glaring clue is this:

    For example, to swap two variables, the author used the non commented following line:

    a ^= b ^= a ^= b;

    This is a cool hack which does not belong to a professional product.

    If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.

    Any time you look at low level libraries, you're going to see things like this. They NEED speed. They NEED low memory impact. These things are going to get called in tight loops with a million iterations. Look at QT's code, and you'll see the same thing.

    Also telling is the fact that he has nothing positive to say about MFC. I've run across some VERY talented developers, and while I haven't heard them singing MFC's praises, they do have some nice things to say. Advocacy really needs to show balance. Acknowledging MFC's strong points is important.

    When he's talking about an add on library called 'codejack', he mentions that tab views are impossible in MFC, yet codejack provides it. Apparently it is NOT impossible in MFC then. It probably isn't a prebuilt widget for the developer to use (which is unfortunate, I'll admit)

    QT is a good library, I have no doubt. But please learn how to find good things in other libraries. It will only make your code better. It will only make your advocacy better.

    • Nope, that's *not* the correct way to code that, even in a high-performance section of code. The correct way is:

      using std::swap;
      swap(a, b);

      If you want to have a nifty hack, then provide a specialization for swap. And don't bother complaining about function-call overhead. If it's really a one-line hack like above, any half-decent compiler will optimize the call away. And if the compiler doesn't, then there's no point in using it to write optimized code in the first place.

      Anyone who can figure out why I used a using-declaration instead of explicitly specifying the namespace (ie: "std::swap(a, b);") gets a cookie.
      • "Anyone who can figure out why I used a using-declaration instead of explicitly specifying the namespace (ie: "std::swap(a, b);") gets a cookie." Or probably should get beaten for spending way too much time reading about an overly complex langauge. My guess is that A. overloading std::swap may be illegal B. swap without the namespace involves an arguement dependant ("Koenig") lookup, so that, if an optimized version of the swap between a and b exists in the namespace that encloses either of them, it will be choosen instead std::swap.
        • Perhaps I deserve it for not previewing and seeing that the formatting was all screwed up :).
        • Beaten... why? I think it's fun :-}

          You're right on both counts. See this Usenet post [google.com] for a little more detail.
          • Fun is solving problems. Learning idiosyncrasies of some overly complex langauge is something that could be done instead in solving problems. It's not fun, it's mental overhead.

            The more C++ I learn, the more I begin to appreciate more elegant langauges like Python or even Java. I think it's nice to look at code and not having to worry about the countless rules, exceptions, etc, that are in C++.

            I wonder how many things like that above I should use my own code. Perhaps I've been doing do much of it, and I should just "dumb down" my code so I can actually get people to help me develop stuff.
      • Do people really have to look any farther to figure out why today's software is so buggy? The more subtle "gotchas" in a language, the more subtle bugs in the resulting products.

        I understand the lure of mastering reams of arcane trivia. In fields like medicine, this is valuable. But, when you have to do so just to use a man-made programming language because of how often things are not what they appear, it is a stinging indictment of the poor design of the language.

    • > But please learn how to find good things in other libraries.

      That's hardly a sign of a well-balanced comparison. You can completely blast a product and still have a fair review--IF the product really sucks in the criteria chosen, and you can fully document why and how it sucks. Unfortunately this author didn't do that, blasting the MFC on generalities without giving specific code examples, which OTOH he was more than eager to provide for Qt. Within the criteria used--OO design and ease of use--the MFC would pitifully fail against Qt, but you wouldn't know it reading this article.

    • Re:Advocacy, we never knew thee. (Score:1, Informative)

      by Anonymous Coward
      [ Philippe Fremy speaking ]

      > It's fast, and it doesn't require a temp variable.

      Yeah, great. But I better have them fix their bugs, their crashes and their memory leaks than spare a temp variable. Besides, the code appears in a function that is not optimised at all.

      You are focusing on the one the example I gave. Does a 500 lines method looks acceptable to you ? Do you think this is also to spare the cost of function calls that they use so many of them ? Or that having private members declared public is good ?

      Their code is crap. It is good in the sense that it makes it a lot easier to build powerful GUI applications and that it works most of the time. But it is crap when you read it.

      > Look at QT's code, and you'll see the same thing.
      The big difference is that in three years of Qt programming, I had just to look once at Qt's code to be sure I understood the doc properly. With Codejock, there are stuff that are simply not documented, and stuff that you can not use if you do not look at the source code.

      > Acknowledging MFC's strong points is important.

      I am sorry, I haven't ran into them, except for the fact that it comes free with Visual Studio. But I'll add any if you have one to propose.

      I recognised we are not good writers. And we made one mistake in this article. We did not point out that we did in no way pretend to be objective. We were just sharing our experience of Qt programming and MFC programming. I'll add a disclaimer in that direction tonight.

    • Re:Advocacy, we never knew thee. (Score:2, Insightful)

      by Anonymous Coward
      a ^= b ^= a ^= b;


      This is a cool hack which does not belong to a professional product.
      If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.
      Uh. I hope you don't really think that. Otherwise, I think it's time for you to go back to school. And no, nothing like that is to be found in Qt. Because its completely wrong, unpredictable, and best of all, the result is undefined. Have you ever read the C FAQ? Or comp.lang.c.moderated? No? I didn't think so.

    • Also telling is the fact that he has nothing positive to say about MFC. I've run across some VERY talented developers, and while I haven't heard them singing MFC's praises, they do have some nice things to say. Advocacy really needs to show balance. Acknowledging MFC's strong points is important.
      Actually I totally agree with you - the author of the article is completely biased. None-the-less it is extremely interesting to note the number of applications Microsoft itself has released that uses MFC.

      According to Don Box (COM guy, now works at Microsoft) the number is 0 - zero! nil! (He mentioned it in his keynote address at Microsoft Developer Days 2001 in Copenhagen)

      Food for thought!
      • Don is wrong. The IDEs for Visual C++ (versions 2 through 6) were all MFC apps. In fact, the original creators of MFC were the ones that wrote the 'new' shell for VC2.0 (the one with the dockable windows). The Doc/View architecture of MFC was derived from the framework for an unreleased product codenamed Sequioa that was destined to become VC2.0, but which was canned in '92 to free resources for shipping VC1.0. I believe PictureIt! was also an MFC app, as is WordPad.
        • Microsoft used MFC quite a lot, mostly in their developer products (AFAICS). If you go to the Microsoft DLL information [microsoft.com] pages and enter the filename of a DLL you'll get a list of released versions; then by selecting "More Information" you can get a list of products that included that version. For MFC, try filenames mfc30.dll, mfc40.dll and mfc42.dll. Many versions of Windows include MFC, perhaps to support programs like WordPad. Various other products include an updated version of one of these DLLs.
      • According to Don Box (COM guy, now works at Microsoft) the number is 0 - zero! nil! (He mentioned it in his keynote address at Microsoft Developer Days 2001 in Copenhagen)

        Would that be the same Don Box who wrote about how COM was wonderful for years, but now says it's crap and we should all use .NET?

        You should be very careful when listening to two-faced Microsoft weenies, particularly when they're demonstrably wrong. MFC was used in writing Visual Studio itself for a long time (though never, AFAIK, in writing things like Office).

    • a ^= b ^= a ^= b;

      If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.

      Bull.

      It's an overly clever hack that doesn't belong in a professional product. Why? Four reasons:

      1. Speed: It is not fast. It's far slower than the typical:
        c=a;
        a=b;
        b=c;
        Don't believe me? Grab a compiler, compile to assembler and check it out.
      2. Storage: It requires exactly the same amount of storage, since the temp will always be in a register anyway (and the same register is required to store the result of computing a^b). Again, if you don't believe me, compile both to assembler and check 'em out.
      3. Correctness: The line as written is *wrong*. It may work with some compilers, but the C and C++ standards both say that the result of the line is *undefined*. Why? You can't apply multiple operations including assignments to the same variables without an intervening sequence point (which, usually, means a semi-colon). The following is correct, although still slower than using an explicit temp:
        a ^= b;
        b ^= a;
        a ^= b;
      4. Clarity: It is not immediately intuitive to anyone. Anyone who has seen the "cool hack" somewhere else will probably recognize it, true, but the use of a temp, or, even better, the use of std::swap() are guaranteed to be understandable at a glance. And there is no real, educational reason why anyone *should* have seen this hack, since it's really not useful.

      The "comparison" article is poor at best, but in this aspect it is 100% correct. XOR-swapping is a cool hack but has no redeeming values other than its coolness, and cleverness for its own sake has no place in professional code.

      • Please pardon my sloppy HTML.

        1. Well, that depends on your compiler. Testing with gcc 3.1 with -O3, I found that gcc has a special optimization for the standard swap construct (I also tried using the Intel compiler, but it produced nasty code that I had no desire to dissect). It assembles to something like this, where the bold variables are registers, and the others live in memory:
          ax = a; //read
          bx = b; //read
          a = bx; //write
          b = ax; //write

          This code has 2 memory reads and 2 writes, whereas the xor construct assembles to a monstrosity with far more memory access than necessary. So yes, on gcc the normal swap is much faster, but a well-assembled xor construct, with just the 4 required memory accesses, would probably only be a few cycles slower, rather than a few hundred. The memory accesses contribute the great bulk of time consumed.
        2. You're not quite right here. Most assembly operations are like operation= in C. There is no temporary register used to store the result of a^b, because the operation is done in hardware as a^=b. You're right in this case that they both use the same amount of storage, but that's only because gcc recognized a common construct and optimized it.
        3. No comment.
        4. It's almost intuitive to people who have learned assembly, but probably not to anyone else. In fact, in light of gcc's particular quirks, hand-written assembly, where the variables are already in registers, is probably the only place xor-swapping should be used. It may be an advantage there, because it only uses two registers instead of three for the normal swap, and on x86, registers are at a premium.
          1. That's precisely the code gcc should emit, and that's what every decent C compiler I've used in the last 12 years has emitted. I don't think it's so much that they recognize the swap construct as the optimizer sees a simple and obvious optimization. Try writing the unoptimized code and look at it as though you had no idea what the original C code said: you'll find the optimization is still obvious.
          2. In fact, I was wrong, for the obscure reason that I had forgotten the x86 has no memory to memory variant of mov, which means that the standard approach does require one more register than the XOR version. Here, to make confusion impossible, consider the following (comments show timings for 386/486 processors -- sorry, only manuals I have handy).

            Standard version

            mov ax, [a] ; 4/1
            mov bx, [b] ; 4/1
            mov [a], bx ; 2/1
            mov [b], ax ; 2/1

            Total: 386: 12 cycles, 486: 4 cycles.

            XOR version

            mov ax, [a] ; 4/1
            mov bx, [b] ; 4/1
            xor ax, [b] ; 2/1
            xor [b], ax ; 6/3
            xor ax, [b] ; 2/1
            mov [a], ax; 2/1

            Total: 386: 20 cycles, 486: 8 cycles

            The XOR approach does have the advantage that it requires only one register, but it consumes so many more cycles that it would still be faster to add a pair of mov instructions to save and restore the contents of bx and then use the standard approach. This would bring the total timings of the standard approach up to 18/6.

          3. This was actually my most important point. A compiler is free (and not unlikely) to emit code that is uses the original values of a and b in every step of the process, which will probably be boiled down by the optimizer to:
            mov ax, [b]
            xor [a], ax

            Now, of course that would certainly be *efficient*....

          4. You almost make a good point here. If a and b are already in ax and bx, respectively, then the XOR swap can be done without involving another register.
            mov cx, ax ; 2/1
            mov ax, bx ; 2/1
            mov bx, cx ; 2/1
            vs.
            xor ax, bx ; 2/1
            xor bx, ax ; 2/1
            xor ax, bx ; 2/1

            So, identical performance (on these processors) but one less register. Here, the XOR swap is a win. It would be a win even if it took a few more clock cycles.

            Now for the explanation of the "almost": Swapping the contents of two general-purpose registers is completely stupid. Instead, the compiler should "mentally relabel" the two registers and go on about its business. Now, some x86 registers all do have special meanings with respect to some of the higher-level instructions, but swapping values around to prepare for execution of, e.g. a REP instruction is something that the C programmer should never even dream of being concerned about.

          I see no realistic situation on any platform I'm familiar with where XOR swapping is a performance win over standard swapping. That's not to say it isn't a win somewhere on some platform, but choosing to write C code that XOR-swaps is a bad idea, because most of the time you won't end up with a better result and you will probably confuse the poor bastard who has to maintain your code later.

    • There are benchmarks showing that using a temporary variable is a ton faster. Should I post a url?
      • I did some tests:

        sh-2.05a$ ./swapbench
        xorswapping 10 secs: 6999572 iterations
        tmpswapping 10 secs: 7785816 iterations

        The code for this is here [hackerheaven.org]. I know it's not really a representative benchmark, but it does show the point somewhat. And yes, using a temp variable is hella faster.
  • That is one thing i have to disagree with the article. MSDN is quite good. And if you are using MFC, then you are using VC++. That means help is usually just an F1 click away.
    • No way, MSDN is terrible. All the information is there (if you can find it), but it's highly scatterbrained and disorganized. Half of the usefull information is locked up in the Knowledge base which is just a listing of sequential articles with no organization to it at all (you have to SEARCH for everything).

      If you compare the API defintions of one API (say ADO) to the API definitions of another (say RegExps) the API documentation is often in COMPLETELY different formats, and we won't even talk about where some of those API docs are located.

      The API documentations frequently don't explain what parameters are supposed to (or allowed to) contain, and even if they do their frequently listed on a seperate page without any explanation of the meanings for the various values.

      Oh, and good, standardised documentation about those COM/COM+ error codes located in a single and easily accessible location? Forget.

      I hate to rant here, but I've been dealing with MSDN's limitations for well over 6 years now and it's hardly better now than it was 6 years ago.

      In all honesty, I can find the solution to my problem 10x faster by going straight to groups.google.com. I find information in the MSDN archive quicker from groups.google.com than I ever do searching for it directly.

      SUN's Java documentation is an example of how things should be documented. It's not perfect, but it's 1000x better than what MSDN offers.
      • Microsofts help was ok when it was in plain help files It just got shit when monkey soft switched to HTML help forcing everyone to install IE.

      • All the information is there (if you can find it), but it's highly scatterbrained and disorganized.

        The index and search are usually good. You very rarely have to browse the contents for stuff.

        Grepping the windows API headerfiles is also very useful.

        The API documentations frequently don't explain what parameters are supposed to (or allowed to) contain, and even if they do their frequently listed on a seperate page without any explanation of the meanings for the various values.

        I've always found them good in that respect - often equal or better than Solaris man pages, say. (IMO, at first glance the QT docs don't look quite as good, but I will give them a better look.)

        Oh, and good, standardised documentation about those COM/COM+ error codes located in a single and easily accessible location? Forget.

        You can get most of them from winerror.h (with some description). Alternatively, there's always the error lookup util installed with Visual Studio.

  • Development tools? (Score:4, Insightful)

    by allanj ( 151784 ) on Monday July 22, 2002 @10:32AM (#3929985)

    As others have mentioned, the article is really badly written. I cannot comment on the merits of Qt, since I've done practically nothing with it. But I've done my fair share of MFC, and it's quite ugly - I find it hard to believe that *anything* solving a comparable problem can be much worse.
    But my main point is this: When dealing with stuff like MFC you need to factor in the quite helpful development tools that the Visual Studio suite consists of. I have yet to see something of that quality from anyone else (except possibly Borland), and so far I've found only KDevelop to be reasonably useful. The MFC library (I flatly refuse to call it an object model) is ugly, but to some extent this is ameliorated by the IDE. I *know* this is not the way it should be done, but it's there and it DOES help...

    • I agree, there's also ATL i think that's even worse!!! I found it far easier to write using straight windows API.

      Fortunatly I wrote my own Windows wrapper before MFC came along.

      MFC might look good in comparison to Visuial Studio which must be one of the worst Dev environments I've ever used, I'd never take a job where Visuial studio was a requirement.

      • Re:MFC (Score:1)

        by RupW ( 515653 )
        I agree, there's also ATL i think that's even worse!!!

        There's a learning curve, agreed, but ATL is very powerful if you want a COM implementation that covers all corner-cases and configuration properly. The ATL with VS7 has been beefed up with MFC-style helper classes (CATLStringW, etc.) and is an absolute dream to use. Honest.

        MFC might look good in comparison to Visuial Studio which must be one of the worst Dev environments I've ever used

        What's wrong with it? IMO, it's a nice editor with a well-integrated (and useful!) source debugger.
        • 1st download a trial copy of CBuilder or Delphi and give there IDE a go...

          Here's my top hates....to the point of frastration.

          1: (this is trully evil) the MDI interface.
          2: Dialogues have loads of tabs but arn't resizeable.
          3: Options arn't natural, e.g. right click on a project and I get .....
          4: (part of 3) Options are hidden all over the place.
          5: MSDN HTML help is shit (not the use of HTML for help, but the way MS have used it)

          Here's a few things in CBuilder Delphi (as an example) that are farrrr superior.

          1: No evil MDI
          2: Options are quite easy to find
          3: Fully RAD
          4: Code compleation is highly typed e.g.
          int a = ...
          only lists things that can return or be cast to an int.
          5: The help is generally quite good.
          6: The api for extending CBuilder/Delphi is great and easy to use (easier than Visual Studio).

  • Qt vs .NET? (Score:2, Insightful)

    by ClosedSource ( 238333 )
    I don't think there are many Windows programmers using MFC for new development. A comparison of Qt and .NET would be more relevant.
    • I wouldn't discount MFC yet for new development (unforutantely). Microsoft released a big update to the core MFC libraries with Visual Studio .NET so they are obviously expecting new development to occur.
      • I wouldn't assume that an update to MFC would imply a lot of new development. The update is useful for legacy MFC applications many of which are unlikely to be ported to .NET.

        I guess if a SW team has lots of experience in MFC and likes it, they might use it for new projects, but I think most Windows developers would prefer to use .NET since that's where future Windows development is going.
    • I don't think there are many Windows programmers using MFC for new development.

      That's an interesting perspective. Personally, I don't think there are many Windows programmers using .NET for new development.

      • "Personally, I don't think there are many Windows programmers using .NET for new development"

        Well, I can't prove that there are, but there were about 5000 programmers who traveled to Orlando back in July of 2000 to learn about .NET (and paid a lot of money to be there). So, I think there is some evidence of interest.

        I can't imagine why anyone writing a new Windows only application would not at least consider .NET.
        • "Personally, I don't think there are many Windows programmers using .NET for new development"
          Well, I can't prove that there are, but there were about 5000 programmers who traveled to Orlando back in July of 2000 to learn about .NET (and paid a lot of money to be there). So, I think there is some evidence of interest.

          Sorry, I couldn't resist the cynical one-liner. In all seriousness, though, I think .NET is much hyped but, so far at least, little used. There are always those who will go with whatever Microsoft produces. They went for Visual Basic first, they went for COM first, and they'll got for .NET and C# first. The remainder of the Windows programming world -- the vast majority -- is more interested in making a product and getting paid for it, and will therefore probably stick with tried and tested solutions like VB6, VC++6 w/ MFC, and so on for a long time to come.

          Microsoft is trying the same trick with the programming world that it's attempted with Windows and Office users recently: produce a new version, with limited new features applicable to a few users only, and hope the bigger version number and hype is enough to get everyone else moving as well. It hasn't worked well so far with office users, and I doubt the programming world (for all their natural instincts to use the latest and greatest) will be any more easily fooled.

          To give credit where it is due, .NET does seem to offer genuine advantages for those writing certain types of application, notably anyone interested in web services. (I don't know why anyone would write for it in "Managed C++", though; if you're doing new development for .NET, you might as well use C# or VB.NET so you can take advantage of it cleanly.) For the average desktop application, though, .NET seems to offer little other than a whole new class library to learn and a whole new massive overhead to install.

          You're right that anyone programming for Windows should probably consider it in their own circumstances, of course. I spent quite some time looking into it during the months running up to its release, from the point of view of writing a typical desktop Windows application. I found no compelling reason to move to the new technology, with all the retraining and redevelopment of libraries and tools that necessarily requires.

        • Most of those people were getting a trip to Orlando at someone else's expense. I probably wouldn't mind doing that whether or not I was interested in .NET.
  • We had an MFC vs wxWindows discussion, where Qt and others were of course brought up, and it was MUCH more informative. See here [slashdot.org].
  • I personally use QT, its feature rich and the cross platform ability is obviously a large benefit.

    As a previous poster mentioned the VCL is really nice too, its just a shame that I have to use Object Pascal to use it I hear a C++ version is coming to Linux though.

    As for MFC I don't really like it, it just doesn't feel object orientated enough!
  • The author's right, QT is far superior to MFC. Cross platform support and a nice, easy to use slot / signal architecture makes my life as an application developer much easier.

    However, MFC isn't that bad. If you're developing a Windows application in C++, and you're forced into using MS only technology cause your boss won't pay the $1000+ per developer license for QT, and your choices are between using MFC and the base Win32 API, then MFC is the way to go. Granted, the Document / View Architecture is uh... well it's *odd*, but once you get the hang of it you can whip out a reasonably good GUI quickly.

    MFC does do some nice things for you, mainly serialization and treating controls as objects, and the Message Maps are a vast improvement over the 10 page switch statements for Message Handling in Win32..

    However, since MFC is "dead", I'd rather see a comparision between C# and Windows Forms vs. C++ and QT.. (and a lot of this I posted on Microsoft's own news groups.. hehehehe)

    Seriously, If you want to see something that's godawful, look at C# and Windows Forms.

    The below is from a post I submitted to Microsoft's own news groups.. to date, I have not gotten any kind of response from Microsoft. A couple of "Wait for Borland C++ Builder.NET" responses.. but nothing from Microsoft. Since MFC is "dead" and .NET is the "way" for Microsoft now, it makes sense to post this..

    Especially if you have an option between QT and .NET... PICK QT FOR THE LOVE OF GOD.

    While trying to develop a dockable tool window (much like the ones found in Visual Studio.NET) I've done a lot of research and had a lot of grief. Out of the box, you can't create a dockable window.

    No one seems to know of any royalty free, open source solutions, and the .NET Magic library doesn't count. Look closely at the source and you'll find that there's an awful lot of Win32 API calls being made via PInvoke, which, per Petzold on page 237 of "Programming Windows with C#", is "no longer writing managed code, and certainly not platform-independent code."

    So for the .NET Magic library users, what's the point of even bothering to use C# and Winforms if all you're using it for is to wrap Win32 API calls? Why not just use C++ compiled as a Win32 app and get the performance increase and greater toolset? I know that making it a dockable window is just a window style, (FWS_something, too lazy to look it up right now, which you would think would just be a property of a Control type, since Control seems to Map 1 to 1 to a Window.)

    Which brings me to the largest gripe I have about the .NET framework: The Winforms really suck. The overly simple UI controls it exposes are simply not acceptable in today's enviroment. First, I'll give Microsoft credit: Visual Studio.NET's UI is absolutely stunning, and the C# language has some nice features....

    However, it is seemingly impossible to create any form of advanced UI unless you derive your own controls or use PInvoke to create GenericPane window classes. And according to Spy++, those nice dockable, resizable windows are of Window Class GenericPane. Seriously, take Docking toolbars for example - we've been able to do this in MFC for years, so using "pure" C# really seems like two steps back instead of the leap forward the PR machine would have you believe. For any kind of advanced UI are we really forced to pony up money for third party libraries or roll our own? (And again, for the goal of "pure" C#, using PInvoke doesn't count.)

    What's really maddening is that there's so many other language / RAD toolkits that do this much better. C++ / MFC, C++ / QT (for cross platform), Java / Swing, to name a few.

    Even the Menus aren't dockable / moveable. What's the point of using managed code if the only applications you can quickly produce look like crap?

    • Serialization in MFC is only nice until you uncover one of its bugs. Like a CArchive of a CList with two to the x plus 10 items is corrupt and can't be reloaded. Where x is 5 or greater by the way.
  • (my apologies to Wired Magazine)

    Tired: MFC
    Wired: System.Windows.Forms

    Anyone creating an app from scratch right now, or porting an app not written in MFC, should _not_ be even considering MFC. New MFC enhancements are usefull for maintaing the (large) base of MFC apps written in it over the last ?10? years. It's time is over though.

    • Anyone creating an app from scratch right now, or porting an app not written in MFC, should _not_ be even considering MFC.

      I assume from the rest of your post that you're advocating using .NET instead? Why on earth would any development team of sound mind do that?

      .NET has precious little in the way of genuine benefit to offer most projects. Its class library isn't much better than MFC in many places, and it introduces a whole new range of limitations and bugs that people will have to learn to work around (if they can). Please don't shout "garbage collection!" or "class library!" at me, because it will cut no ice. The use of either limits you so seriously that you might as well give up all the good things about C++ and other libraries available for it and use C# instead; "managed C++" isn't really C++ at all.

      MFC, OTOH, while kludgy and less than well-designed, has a developer base of zillions across the world who know how to work around its kludginess and get the job done. It is tried and tested, so at least you have a pretty good idea where the bugs are. There is a lot of truth to the old saying "Better the devil you know".

      If I had a new development team starting on a Windoze app, MFC certainly wouldn't be my first choice of tool -- far from it -- but it would be waaaaay ahead of anything to do with .NET.

  • MFC is NOT replaced by Windows Form (Score:3, Informative)

    by edyu ( 259748 ) on Monday July 22, 2002 @04:36PM (#3932894)
    I don't know why everyone is claiming MFC is no longer in the picture after .Net. It's like claiming Newspaper was dead after TV came out. Here is an excerpt from MSDN:

    It has been three years since the last major update to MFC and ATL. With all the press on Microsoft® .NET, MFC and C++ developers may be feeling left out. But don't worry--with the upcoming release of Visual Studio .NET, not only do developers using Visual C++® get a brand new IDE with tight integration for server-side development and a much improved C++ compiler, MFC and ATL have also received significant new features. The clear message is that MFC continues to be a great framework for developing sophisticated, rich client applications for all Windows® platforms. In this article, we'll provide you with a survey of the new features that you can use in your MFC applications.

    There's a new MFC DLL (MFC70.DLL) that is no longer backward binary-compatible with MFC42.DLL, but your source is still compatible (although message maps have been made more type-safe, so that may break some code).

    MFC and ATL are much better integrated, and common classes such as CString are now shared between the two libraries.

    Header files are synchronized with the latest Platform SDK, supporting UI features in Windows 2000 and Windows XP such as themes and manifest resources, Active Accessibility®, and new common dialog boxes.

    Many new UI classes have been added, including support for using DHTML in dialog boxes and enhanced bitmap support with CImage.

    New utility classes can be used in both MFC and ATL applications, such as regular expressions, performance counters support, and security.

    Now there's support for consuming Web Services in MFC applications and writing Web Services and applications with ATL Server classes.

    High-performance access to databases has never been easier using the new OLE DB attributes and classes.

    STL has been updated.

  • A bit *too* nice about Qt (Score:3, Insightful)

    by Anonymous Brave Guy ( 457657 ) on Monday July 22, 2002 @09:51PM (#3934553)

    I can't help feeling that, whatever its position on MFC, the article was unjust in its uniform praise of Qt. Some of the container classes there (QMap?) appear to be somewhat inferior versions of the STL equivalents, in case the C++ library in use doesn't support the STL parts properly, but doesn't support all the template guff required to use them(?!) To their credit, they do at least try to support the standard interfaces so you can use their containers with standard algorithms, which is a definite improvement over MFC.

    The article also seems to praise QString, which is yet another string class with a Big Bloated Interface(TM) (doh!) that thinks using only mutable strings is the way forward (double-doh!) and reference counting/copy-on-write of a mutable string is a Good Thing (double-plus-doh!). These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc. If they wanted an improvement, they should have provided an immutable string class with a suitable set of operations, and a string-building framework to go with it where it's genuinely the appropriate tool. Oh, and being in native Unicode isn't particularly clever. Why not just use std::wstring, anyway?

    As for the graphics, sometimes I want to lay out my dialog controls in exactly the positions I decide to put them in. Dynamic generation can be a good thing, but don't mandate it, because sometimes it's simply wrong.

    I also have quite a bit of experience of i18n, and I'm all-too-familiar with the pain of translations, etc. For those who don't know, l10n (the opposite to i18n, i.e., making your location-generic application work in a specific locale) is about 10% translation and 90% integration, fixing up all the dialogs, ensuring that your UI can cope with reordered sentences (hope you don't like the IOStreams approach; printf had it right years ago) and so forth. A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.

    Don't get me wrong, I think Qt is a nice library, and much better than many of the alternatives. But some of the claims in the article are just downright false.

    • Re:A bit *too* nice about Qt (Score:1, Interesting)

      by Anonymous Coward
      > These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.

      In 3 years of development with Qt, I haven't met any of the problems you describe. Maybe I am not writing the right programs.

      > If they wanted an improvement, they should have provided an immutable string class with a suitable set of operations,

      You mean a QConstString [trolltech.com]

      > Oh, and being in native Unicode isn't particularly clever.

      This is a comparison with MFC. You are telling me that their choice is really stupid and I agree. In comparison, the other choice looks clever.

      > As for the graphics, sometimes I want to lay out my dialog controls in exactly the positions

      You can do it if you want, even with Qt Designer. But I don't see when you want to do that. Could you give an example ?

      Anyway, in the big majority of case, you want things to layout automatically and it is easy to do that with Qt.

      > ensuring that your UI can cope with reordered sentences

      QString can deal with reordered arguments.

      > A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.

      Yes it is. gettext() had it right from years. This approach allow the developer not to worry too much about translation, allow the translator not to cope with compiling stuff and get automatic update, and allow the user to add new language without hassle and to switch easily from one language to another.

      Qt uses exactly the gettext() approach, with their own tools.

      • These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.
        In 3 years of development with Qt, I haven't met any of the problems you describe. Maybe I am not writing the right programs.

        Maybe you've been lucky. Who knows? The fact remains that there are demonstrated problems that can occur when using COW strings in a multithreaded C++ system, and further, the advantages of using such a design are mostly illusory anyway. It seemed like a good idea at the time, but on reflection, it turned out not to be. (BTW, I have watched an application fall over for no good reason because its string library wasn't multithread-safe when it should have been, and I've watched the development team waste several man-days of time trying to find the bug in their code -- which wasn't.)

        If they wanted an improvement, they should have provided an immutable string class with a suitable set of operations,
        You mean a QConstString

        I don't think so. I mean a full-fledged immutable string class that supports the usual look-up and combination operations without the mutating ones, and a clean interface to convert between such a class and a vanilla QString. AFAICS, that's a whole world away from QConstString.

        You can [lay out dialog controls in exact positions] if you want, even with Qt Designer. But I don't see when you want to do that. Could you give an example ?

        In simple cases, I agree, an automatic layout can be very helpful. OTOH, on a program I used to work on, extensive used was made of tabbed dialogs. The layouts of most of them were fixed across all of the tabs, so that similar controls didn't jump around irritatingly as you flipped from tab to tab. I don't know if Qt's automatic layout system would handle that, but certainly no other one I've ever seen does. Automatic layout is simply not the best answer to everything, which the article seemed to be suggesting.

        A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.
        Yes it is. gettext() had it right from years. This approach allow the developer not to worry too much about translation, allow the translator not to cope with compiling stuff and get automatic update, and allow the user to add new language without hassle and to switch easily from one language to another.

        With all due respect, if you think a simple translation mechanism like that is all there is to i18n/l10n, I can't believe you've ever worked on a large-scale multi-lingual application. There are other locale-related formatting issues (date/time, currency, etc). There are languages where routine system calls don't work on some strings (try a toupper on the German word Strasse, and then try the same on the same word written with a Schaffes s, and then compare them for equality). In Japan, most machines speak MBCS, not Unicode, so you need an effective means of converting between them, preferably as soon as the MBCS enters your program and just before it leaves so you can at least use Unicode internally. Some languages read right-to-left, or top-to-bottom, or even more devious variations, and you have to adapt your UI to cope with this, particularly when laying out dialog boxes and such. It is not as simple as a tr() function. (I'm not saying Qt couldn't cope with many of these issues, just that the emphasis placed on the tr() function by the article is overstated.)

      • A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.

        Yes it is. gettext() had it right from years. This approach allow the developer not to worry too much about translation, allow the translator not to cope with compiling stuff and get automatic update, and allow the user to add new language without hassle and to switch easily from one language to another.

        A major problem with gettext() is that there can only be one translation of each of the strings in the original language. What happens when you use an English word with different meanings in different contexts, that should be translated to separate words in another languages? Usually your messages will be long enough that this doesn't happen, but in a GUI you may well use text labels with only one word in them.

    • Some of the container classes there (QMap?) appear to be somewhat inferior versions of the STL equivalents, in case the C++ library

      Qt is pre-STL. Also, it makes different design tradeoffs. The containers are pointer-based, and are implement using the "inheritance from void*" container idiom which means that the "template bloat" is minimised in these classes. It makes sense in Qt, since Qt programs use pointers and not values.

      These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.

      They weren't well-known at the time Qt was written. gcc still ships with a reference counted std::String today.

      Why not use std::wstring

      It wasn't an option when Qt was written. You're writing this as though Trolltech had full benefits of the ANSI/ISO 1998 standard at the time they implemented it. Qt was written in 1996.

      • Sorry, didn't mean to come across as bashing Qt. I realise it was first created pre-standard and couldn't have benefitted from the experience gained by the C++ community over the past five or so years. I was trying to highlight flaws in the evangelism of the original article by citing obvious concrete examples of false claims (containers better than STL, yada yada).

        • I was trying to highlight flaws in the evangelism of the original article by citing obvious concrete examples of false claims (containers better than STL, yada yada).

          I agree with the overall impression. The article comes across as cheerleading, and not a balanced comparison. I haven't used MFC, but I find it hard to believe that it's as bad as they make it sound. The containers are adequate, but the design is not as clean as STL, and there are some benign warts like "current" nodes in lists, and index based access in lists (I say bening, because one can just ignore these misfeatures).

    • The article also seems to praise QString, which is yet another string class with a Big Bloated Interface(TM) (doh!) that thinks using only mutable strings is the way forward (double-doh!) and reference counting/copy-on-write of a mutable string is a Good Thing (double-plus-doh!). These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.

      Can you explain these inefficiencies, or provide a URL to some analysis about them? Personally, I think the copy-on-write stuff is really cool. Not just QString, but even container classes like QValueList won't duplicate your objects unless needed. Native Unicode makes things simpler too...

      • The best exposition I've seen was a set of three articles on "Reference Counting" in Herb Sutter's Guru of the Week [www.gotw.ca] series. You can find articles 43-45 on his web site, and as he notes there, an updated version is available in one of his books. You could also search the history for the Usenet group comp.lang.c++.moderated, where GotW is posted, to see more discussion on the subject. You might also want to check out the most recent GotW (questions but no solutions on the web site, but check the newsgroup history) for a few thoughts on why string classes tend to have overbloated interfaces.

  • I've some experience with MFC but not QT. I don't think you've correctly understood the MFC model. (Colleages recommend Prosise's [amazon.com] book by Microsoft Press but it's been a long time since I've seen a copy.)

    The Microsoft Foundation Class (MFC) is a graphical toolkit for the windows operating system. It is a more or less object oriented wrapper of the win32 API, which causes the API to be sometimes C, sometimes C++, and usually an awful mix.

    The only non-C++ you could complain about in MFC is the use of some Win32 API structures without containing classes/accessors. Under the circumstances (given the number of them!) I don't think this is too big a deal.

    MFC programming requires the use of Document/View model and templates.

    No, it doesn't. If you don't want Doc/View, you can just use the MFC-dialog-application template.

    I've never seen the other problems you mention:
    • you can probably ditch the document/view model (I've never tried) but you can easily bury it if you don't like it and I've never found it inflexible enough to be a hinderance. Cite an example?
    • I wouldn't be surprised if splitting a window to show two different documents probably violates the windows UI design guidelines. You can get equivalent function using an MDI app (although I think the guides have deprecated those) or implement a 'document container' class or something. You probably don't need too much imagination.
    MFC is a kind of object wrapper allowing access to the windows API,

    I'd consider this a plus - lean (or as lean C++ as you'll get), efficient (ditto) and feature-complete.

    And there are nasty tricks, without any consistency. For example, if you create a graphical object, it is not created until the Create() methods has been called. For dialogs, you must wait for OnInitDialog, for views, you wait for OnInitialUpdate, ... So if you create an object manually and call its methods, your program crashes.

    No. This *is* consistent and logical. And OO.
    1. When you create a CDialog, you create a container class for a window handle with dialog-like methods. You may set up the initial state of the dialog, member variables of the container class, etc. But because you have an empty handle you can't actually play with the dialog yet.
    2. You Create() or DoModal() your CDialog object. Now the windows is actually generated on the desktop and the window handle is filled.
    3. You're called back in the OnInit* method to set any state on the window as it is created. You may now call methods that require a window handle.
    I don't think MFC will crash - I think it'll give you a useful debug assert. But I haven't fallen into that trap for a while.

    MFC is full of these nasty tricks. And it is hard to debug.

    'nasty tricks' is a little extreme. MFC integrates very well with Visual Studio's debugger and is relatively simple to debug. You're provided with the source code to step through if you need it. I've never had any trouble.

    Qt is based upon a powerful callback mechanism based on signal emission and reception inside slots.

    This sounds exactly like the Windows message model that you've just slammed (!). I don't see any problems with the windows message model - but then I'm familiar with the API.

    The interface creation section: DDX and IMPLEMENT_DYNCREATE (why do you need that for your UI?) are relatively easy to understand - maybe try Prosise's book if you need enlightenment. You don't need to touch the message loop - it's buried in the MFC DLL and covers all cases. You can quite happily manufacture dialogs at run-time by calling Create() on control objects in the OnInitDialog() method.

    Qt designer lets you do things that are not possible in MFC, like creating a listview with pre-filled fields, or using a tab control with different views on each tab.

    Pre-filling a list view should be done in OnInitDialog(); the interface is quite simple.

    Tabs are a different matter; you need to create child dialogs for each separate pane. This closely reflects what's going on in the OS API. It's not too difficult and there are good sample applications. Alternatively, there's a very simple interface to create complex property pages already provided.

    Visual's documentation, MSDN (for which you must pay separately) is huge, on 10 CDROM.

    It's no more than 3 CDs. It's bundled with Visual Studio. It's available online at http://msdn.microsoft.com/library/ [microsoft.com]. And it's very good, complete documentation.

    MFC's unicode is very easy. If you need to change the entry point of your application then you're doing it wrong; you probably need to change /D_MBCS to /D_UNICODE and it should happen automatically. The _T() is to tell the compiler to generate unicode character constants. It's a MFC/Win32API macro that emits syntax for the compiler. There must be a similar mechanism in QT or you won't be able to pass it unicode constant strings. If you build your application with the correct Unicode defines then the CString class will be Unicode internally automatically (but will still support some char* functions). If you build your application ground-up Unicode (and you should be doing this - NT is natively unicode) then you'll have no problems; Unicode converting an existing app isn't as hard as you portray.

    If you're given non-unicode third party library then the third party ought to be able to supply a unicode version by changing a few flags and rebuilding. I'd be surprised if many vendors couldn't supply Unicode libraries if you asked them.

    Resources and string-tables are part of the Win32 API. I find them useful and easy to program for. You have to try quite hard to load resources from the wrong DLL; all resources are indexed on exe/dll module handle as well as resource ID.

    Latest MFC DLL: you should always ship the one you develop and test against! Win2K+ allows you to install a copy of the DLL local for your application. Alteratively, there are simple-ish mechanisms to auto-download the latest MFC from Microsoft.

    To address some of your list of QT advantages,
    • Controls... MFC uses native OS widgets which is arguably an advantage for Win32 programs: correct look and feel and always do exactly what a Windows user would expect.
    • MFC does provide classes for network and database access
    • Memory management shouldn't be a problem; if you create controls as members of the containing dialog class then they'll be destroyed automatically too. MFC's debug memory allocator is good, too.
    I've never used CodeJock.
  • The main problem with QT is this thing called MOC, some kind of preprocessor you need to run. Then of course, there's the license fee for use in any commercial software. Other than that, there's just the use of Expose events in X11 making it slow and ugly.

Slashdot Top Deals

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Close