MFC sucks

This is a discussion on MFC sucks within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Ok, ok, ok. So MS didn't like the C++ language the way it was. So they made it 'easier' with ...

  1. #1
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598

    MFC sucks

    Ok, ok, ok.

    So MS didn't like the C++ language the way it was. So they made it 'easier' with crap like this:

    Code:
    / Overrides
    	// ClassWizard generated virtual function overrides
    	//{{AFX_VIRTUAL(CMapView)
    	protected:
    	virtual void OnDraw(CDC* pDC);      // overridden to draw this view
    	virtual void OnInitialUpdate();     // first time after construct
    	//}}AFX_VIRTUAL
    And I've seen afx_msg void Func_name(). Unless afx_msg means virtual...what else is going to go in front of void in a C++ program??

    And what the heck is //{{ //}}?

    Oh and to create a class with a PROTECTED constructor I don't make the constructor public...I use this:

    Code:
    CRuntimeClass* pRuntimeClass = RUNTIME_CLASS( CMyClass );
    CObject* pObject = pRuntimeClass->CreateObject();
    ASSERT( pObject->IsKindOf( RUNTIME_CLASS( CMyClass ) ) );
    Wow thanks MS, that really clears the air for me.



    What the heck is all this garbly gook and how am I supposed to use it? I feel like I'm learning an entirely new language here.
    Too many macros.

  2. #2
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    I think the ClassWizard uses //{{ and //}} to know where to add more "garbly gook".

    I agree. I've been working with MFC for at least six months now, and I still don't get it.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  3. #3
    Registered User
    Join Date
    Aug 2004
    Posts
    77
    I messed with MFC for a couple of weeks. I got tired or sorting out all the MS crap that gets thrown in there by the wizards and whatnot.

    The standard C API calls work fine for making GUI's from what I can tell. They don't seem to look as pretty, but if you tinker enough with the flags and settings you can get then looking pretty good. The only real downside is that withough playing with MFC a lot of the COM and .NET libraries will be a real pain to get working.

    Its been my opinion that just about any program that tries to generate code for you just causes problems. Its always some mystifying stuff like that, that mere mortals weren't meant to understand.

  4. #4
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    University of Waterloo
    Posts
    1,904
    I can't stand MFC. period. I've dabbled with it a little bit, but there's way too much overhead with it. I prefer just straight Win32 as it gives you probably the best access to the API without having to do anything overly complicated or that will make code unreadable.

  5. #5
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    I can definitely relate to the feelings of, well, everyone who's posted so far. I've been using MFC for about 4 years now (self taught) and I was completely lost in the beginning (reading a book helps too), but it's funny because I was never really angry about the complications I was faced with, but of course that's just me. MFC is such a complicated animal because, as you could probably guess, it was built in an attempt to surround the API with OOP while always considering complications with execution.

    The //{{ and //}} guys are there for MSVC. Without them the IDE wouldn't know where to add/change/delete the things it sticks in there automatically. afx_msg is there for a similar reason. It might please you best if you simply ignored those things altogether because, generally speaking, you do not need to use those things in any code you write yourself and you shouldn't have to modify any of that stuff directly.

    MFC really isn't that bad. What you're experiencing is the effects of trying using AFX and the classwizard, etc. If you were to write an MFC application by hand, without any automatically generated code, you'd see how very simple it really is. In my opinion it is much better than API programming because it provides the same control, but through an interface that is much easier to use. You just have to derive a CAppWin class and you can go from there.

    To all the haters:
    Don't give up on MFC just yet. It has a lot to offer. Try reading Programming Windows with MFC by Jeff Prosise. You'll be very glad you did. Really.

  6. #6
    Registered User
    Join Date
    Aug 2003
    Posts
    470
    Bubba, it's not that hard once you get used to it. There are few classes that are too close to the underlying api. For instance, CDialog is designed poorly, and requires filling in winapi structures. As for your complaint about the RUNTIME macros, MFC uses the them because MFC was developed before runtime type information was added into C++.

    jverkoey, MFC runs fairly fast, at least on my computer, and that's really something.... There might be increased size to your program, in both memory and harddisk space, but the benefits compared to the winapi are worth it, I think. Furthermore, what's usually slowing down your program is not the GUI(unless your using Swing), but something else.

  7. #7
    Registered User
    Join Date
    Aug 2003
    Posts
    470
    I meant CFileDialog, my bad.

  8. #8
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    University of Waterloo
    Posts
    1,904
    Quote Originally Posted by okinrus
    jverkoey, MFC runs fairly fast, at least on my computer, and that's really something.... There might be increased size to your program, in both memory and harddisk space, but the benefits compared to the winapi are worth it, I think. Furthermore, what's usually slowing down your program is not the GUI(unless your using Swing), but something else.
    Well, I can't say I know what Swing is other than the Java GUI's Swing.....however, I'm perfectly happy with the speed that my win32 programs run and I've created my own classes for win32 which, IMO, work a lot nicer and easier than the MFC ones.

  9. #9
    Registered User
    Join Date
    Aug 2003
    Posts
    470
    Well, I can't say I know what Swing is other than the Java GUI's Swing
    Yes, Java Swing is what I meant. Because Swing is non-native and implemented in Java, a fairly large swing application will run very slow on my computer.


    .....however, I'm perfectly happy with the speed that my win32 programs run and I've created my own classes for win32 which, IMO, work a lot nicer and easier than the MFC ones.
    Have you tried wxwindows(wxwidgets)? wxwindows was first written using MFC, but now uses the winapi.

  10. #10
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    While MFC looks ugly and has some minor design uh... core meltdowns, I really can't imagine doing Dialogs in WinAPI. That has to take AGES. Or you have to write your own framework, which is bound to the same mistakes... five more years of C++ experience from now, it will look and feel horribly misdesigned.

    Best advice so far in this thread: If it looks like an MFC macro, just don't touch it.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Well I tell all the new graphics programmers to go and buy books if they want to learn anything, so I'm heeding my own advice and have several MFC books on the way.

    It won't beat me and I'm gonna learn it if it kills me. I have to learn it in order to create good tools for my games. I realize that .NET probably nullifies all this MFC stuff and I'm probably very late on the scene for MFC...but I still need to learn and master it.

  12. #12
    Registered User
    Join Date
    Mar 2003
    Posts
    580
    I hope you don't spend too much time on this stuff because you could instead be spending time working on the other cool stuff you've posted. It might be better to just write game tools in Visual Basic. Some reasons why:

    -It's easier to make applications that look better
    -It's faster to throw together win32 applications
    -When something goes wrong it's easier to find problems in visual basic
    -Little 'support' is needed to keep the code working once it's written

    To be fair I don't know how 3D graphics run with VB, and if you're doing something like a complex map editor where you need to have a 3d representation, then it might suck.
    See you in 13

  13. #13
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    University of Waterloo
    Posts
    1,904
    Quote Originally Posted by nvoigt
    I really can't imagine doing Dialogs in WinAPI. That has to take AGES. Or you have to write your own framework, which is bound to the same mistakes... five more years of C++ experience from now, it will look and feel horribly misdesigned.
    That's why visual studio's resource editors rock, heh. All forms I make, I just draw using visual basic's tools. The only code I have to do that involves positioning the actual controls is putting the code in in the case that I allow the window to be resized, in which case I have to take in to account the new size and size the window accordingly.

  14. #14
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I made my first tools in VB and wanted to call my engine DLL from VB but really had no idea about how to go about mixing the two languages. The core engine DLL is all I need and it only needs to know what objects are on the map and their orientation. When someone places an object I would simpy create that object and add it to the vector. Since that object is the selected object I would flag it somehow and the engine DLL would draw a 3D wireframe cube around it indicating that item is the current selection. Multiple objects would just be a matter of flipping flags or booleans.

    However there are a lot of issues to deal with as I make the editor. Syncing the two applications and sending messages from my editor to the DLL is not a trivial task. There are many approaches to take, but I'm currently undecided about all of them.

    It is a big test of my programming skills because I need to combine Windows GUI with windowed Direct3D and also track the mouse in 3D space when it is in the render window.
    I've used several map editors for current games out there now so I have a good idea about what needs to be done. I want to make it as simple as possible to create missions and/or levels that my engine can use. I also want to support custom vertex and pixel shaders and allow the tool to switch shaders and apply the switch local to any object. How it looks in the editor is how it will look in the game. I would also like for the editor to allow the user to script an entire DirectX effect file complete with techniques, vertex shaders, and pixel shaders. The editor would then compile it and then compile it into a resource format of my own choosing. It can get quite complex if you think about all that has to be done.


    But...as I said this is a major challenge...however without it my game can only progress so far. Right now it's screaming at me that it needs some tools.
    Last edited by VirtualAce; 02-02-2005 at 10:57 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How Cool is Java
    By dukemarlon in forum A Brief History of Cprogramming.com
    Replies: 24
    Last Post: 11-28-2002, 05:24 PM
  2. WIndows programming?
    By hostensteffa in forum Windows Programming
    Replies: 7
    Last Post: 06-07-2002, 09:52 PM
  3. Release MFC Programs & Dynamic MFC DLL :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-18-2002, 07:42 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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21