Thread: Ok so MFC isn't dead.

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    But that's you. Thousands upon thousands find MFC a good tool because it hides away the complexity of the Win32 API.
    As Bubba mentioned, I could probably make a dialog in MFC as fast as in C#. With Win32 API only, it would take me a year (OK not really, but you get the point).
    It's not the tool of the devil. It's a great tool. But it may not be for those who hate overhead and want to mess with the basic, underlying structure.

    So, out of curiosity, do you prefer assembly over C/C++ too?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    Quote Originally Posted by abachler View Post
    I like being close to the metal, the metal is GOD. Since MFC is far from the metal, it is far from GOD. While it is not quite the devil itself (that would be Visual Basic), it is certainly something that assists the devil is leading people away from the straight and narrow path, hence the appelation 'tool of the devil'.
    You sound like you have issues bigger than MFC.
    Last edited by indigo0086; 12-21-2007 at 11:50 AM.

  3. #18
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Elysia View Post
    So, out of curiosity, do you prefer assembly over C/C++ too?
    Yes. Ive used assembly on every intel processor in the 80x86 family except the 286, and a few pre-8088 processors and several microcontrollers. When performance matters, assembly is the only way to go, it even beats using intrinsics if you know what you are doing. Obviously there are parts of any application where its easier to just use WinAPI (creating threads for example).

  4. #19
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    I agree with indigo.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #20
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    I wonder what holiday he celebrates? Ozzfest?

  6. #21
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,398
    Quote Originally Posted by Bubba View Post
    So I don't understand the argument that somehow because people use C++ they are somehow dissing C? This makes no sense to me.
    Who said that? I was just asking if anybody else wrote Windows apps in C.

    The GUI is such a minor part of our product in terms of absolute effort...

  7. #22
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    Quote Originally Posted by brewbuck View Post
    MFC? Does nobody write straight WinAPI anymore? For that matter does nobody program Windows in C anymore?
    I wrote a C program using the Windows API for someone. They said they didn't have a language preference as to what I used, so I went for C. It was quite an experience.

    I would actually say it was fun.

  8. #23
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,608
    Most of the problems I have in MFC are not from MFC but from the Windows Common Controls. Some of them are broken in some manner and most of them feel rushed out the door. I think MS's design philosophy was: " eh they will subclass our controls anyways so who cares."

    What's with having a CListBox that does not add a scrollbar for strings that stretch beyond the client rect?

    What's with having a scrollbar in CListBox that does absolutely nothing. This is an admitted bug that has never been fixed.

    And there are some annoying supposed 'by design' issues in MFC such as popup menu items not having their ON_COMMAND_UI handlers called. MS released code to remedy this but the core design seems flawed and should have never left w/o taking this issue into account.

    Drag and drop is a pain too without OLE/ActiveX. It's like MS couldn't figure out whether to force the coder to use OLE, subclass the control (and thus not be able to use the resource editor on their control), or hack together some other message based method. The docs in the SDK are less than helpful in this area.

    So I'm not saying MFC is perfect but it is a nice tool and does for the most part speed up GUI dev.
    Last edited by VirtualAce; 12-21-2007 at 05:30 PM.

  9. #24
    Registered User Dante Shamest's Avatar
    Join Date
    Apr 2003
    Posts
    970
    When I do any Windows programming, it's almost always with the Windows API using C++.

    Yes, the raw Win32 API is convoluted and quite messy, but I wrote C++ wrappers for most of the things I want to do already a long time ago. So now whenever I want to begin a new project, I just use my existing wrappers.

    I don't use MFC much because I'm just a hobbyist windows programmer. (I'm a Linux/Java programmer by profession.) So I prefer to use the free development tools out there (Dev-C++,Code::Blocks). If I wanted to use MFC I'd have to purchase Visual Studio, and my programs would have to distribute the MFC DLL or statically link to it.

    But if I were professionally making desktop programs, I'd see the value of using MFC, as most professional 3rd-party toolkis for Windows (such as CodeJock and Xtreme ) do seem to be designed for it.

    Having said that, I don't even code using the Win32 API as much as before. I switch between Windows and Linux alot now, so I've been trying to adopt alternative APIs such as SDL and wxWidgets for any graphical stuff.

  10. #25
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Quote Originally Posted by abachler View Post
    When performance matters, assembly is the only way to go
    I'm not sure that is true anymore. Compilers are capable of some insane optimizations that most programmers would miss if coding the assembly themselves.

    Oh and WinAPI forever. Nothing like having a 10 pound book and 200 lines of code before getting anything worthwhie done.

  11. #26
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    I'll admit that the WinAPI is messy, but hell it's easy to use. You'd have to be a moron not to work out how to use it, and you can create and implement things fairly quickly with resource templates.

  12. #27
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Thantos View Post
    I'm not sure that is true anymore. Compilers are capable of some insane optimizations that most programmers would miss if coding the assembly themselves.
    I have generally found that while the compiler does a good job of optimizing, it cant optimize for every possible intended use, it has to generate code that is bulletproff no matter the intention fo the programmer. Having first hand knowledge fo the actual effect you wish teh code to have gives one the advantage when hand optimizing the code. I guess it just comes with experience really, as I said, ive been writing assembly for a very long time. I certainly woudlnt want to write an entire application in assembly, as it would be exhausting. On the other hand, I dont want MS takign away my favorite tool becasue its 'too hard' to implement it for x64. You dont use a scalpel to cut down a tree, but you dont use a chainsaw to do brain surgery either. A case in point is processing 2 vectors. The compiler does a crap job of generating the loop structure, where hand coded assembly using the LOOP instruction can speed things up significantly. Dont even get me started on the implementation of CopyMemory as apposed to REP MOVSD. The compiler isnt set up to make judgement calls, such as slowing the program by pushing a few registers to the stack in order to use a much faster method for a big task. The SSE intrinsics generally generate unaligned code for vectors whose alignment is unknown, whereas I can write seperate sections that decide at run time whether to use aligned or unaligned opcodes. Not to mention doing things like using integer registers like EAX to hold floating point values. Compilers are good, but they cant beat a good coder that knows the metal.
    Last edited by abachler; 12-22-2007 at 12:31 AM.

  13. #28
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,792
    Quote Originally Posted by abachler View Post
    I have generally found that while the compiler does a good job of optimizing, it cant optimize for every possible intended use, it has to generate code that is bulletproff no matter the intention fo the programmer. Having first hand knowledge fo the actual effect you wish teh code to have gives one the advantage when hand optimizing the code. I guess it just comes with experience really, as I said, ive been writing assembly for a very long time. I certainly woudlnt want to write an entire application in assembly, as it would be exhausting. On the other hand, I dont want MS takign away my favorite tool becasue its 'too hard' to implement it for x64. You dont use a scalpel to cut down a tree, but you dont use a chainsaw to do brain surgery either. A case in point is processing 2 vectors. The compiler does a crap job of generating the loop structure, where hand coded assembly using the LOOP instruction can speed things up significantly. Dont even get me started on the implementation of CopyMemory as apposed to REP MOVSD. The compiler isnt set up to make judgement calls, such as slowing the program by pushing a few registers to the stack in order to use a much faster method for a big task. The SSE intrinsics generally generate unaligned code for vectors whose alignment is unknown, whereas I can write seperate sections that decide at run time whether to use aligned or unaligned opcodes. Not to mention doing things like using integer registers like EAX to hold floating point values. Compilers are good, but they cant beat a good coder that knows the metal.
    A long while ago, we held a programming contest to do a brute force activity as fast as possible - you choose the platform, you choose the langauge....etc - just do it as fast as possible. I entered and used inline ASM. I had all the optimisations set for the compiler, tried to use APIs to speed up the code, used a few inline tricks to tell the compiler to leave my ASM alone and not add extra code to it. I spent ages profiling the code, switching instructions, juggling registers and doing everything I could to get it to go faster. The end result was very quick and smoked most other entries, but another member of this board submitted an entry which was almost all standard C++ code (very cleverly done) and his speed was so close to mine that it was almost identical (his was 0.009ms slower). When you looked at the other entries, they were well behind the two of us.

    Now maybe I'm not a "great" ASM coder (I dont profess to be) and maybe someone else could have done even better, but the point that I got from the exercise was that all that extra work trying to outdo the compiler was lhow yourargely a waste of time - if you know your tools and the language and how your system works, you dont need to rely on assembler.

    There may be times when some knowledge of ASM is needed - working with hardware and it can help with debugging. But those occurances are getting more and more rare.

    Ive been on these forums for quite a long time, not as long as people like Salem and nvoigt, but long enough to have heard and taken part in every "this-way-is-faster" or "this-way-is-better" posturing that there can be. Ultimately, I've come to the following conclusions -

    1. Knowing all the tricks and dark arts isnt worth much in the majority of cases but can be nice to know
    2. Knowing your language, tools and basic system is very important and will give you more than trying to figure out how to break or fool those things.

  14. #29
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #30
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,868
    One thing I like about MFC is that it 'asserts' on exceptions rather than crashes (as WIN32 does) allowing more chance to handle the error.

    One thing I hate about MFC is that it 'asserts' at every opportunity. ie setting a CTime to less than 01/01/1970.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WIndows programming?
    By hostensteffa in forum Windows Programming
    Replies: 7
    Last Post: 06-07-2002, 08:52 PM
  2. Release MFC Programs & Dynamic MFC DLL :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-18-2002, 06:42 PM
  3. Understanding The Future of MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 04-15-2002, 09:08 PM
  4. Beginning MFC (Prosise) Part III - Now What? :: C++
    By kuphryn in forum C++ Programming
    Replies: 5
    Last Post: 03-03-2002, 06:58 PM
  5. MFC is Challenging :: C++
    By kuphryn in forum C++ Programming
    Replies: 8
    Last Post: 02-05-2002, 01:33 AM