CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 26 of 26
  1. #16
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by Ajay Vijay
    Function calls does not matter now days? Are you sure? Have you seen the coding, by tracing, behind the AfxGetApp? Well that's a complex one. So it is better to use 'theApp' directly if call is from same executable or use it once store it in a CWinApp pointer, if desired on other executable (DLL for example - on which your app is dependent).
    Are you really trying to tell me that a function call overhead of x nanoseconds does matter much to you? I can understand that for embedded systems where system resources are limited but with nowadays systems' I do not see much reasons to care about one function call...

    The code of the 'AfxGetApp()' is displayed above...however I did not follow the complete path of subfunctions it calls. Nevertheless, AFAIK all these functions are implemented as either inline functions or macros therefore the overhead of a function call will be eliminated while compiling...

  2. #17
    Join Date
    Apr 2003
    Location
    Oklahoma City, OK
    Posts
    7
    There is some interesting discussion going on here, but I don't think we are digressing from the true spirit of the question. If you are writing code and have access to the global CWinApp variable (theApp) the MFC defines by default, there is no reason not to use it. Yes, the function overhead might not be all that costly, but why introduce it when you don't have to.? The size of your executable is going to increase with inline function calls and macros as well. They are not all implemented as inline and macros in VS .NET, anyway. Step into a call of AfxGetApp(). There is a lot of overhead associated with getting the module state and thread data. Overall, I think you should use theApp except when you are intentionally writing code that you want to be able to share across applications without modifying anything.

    James

  3. #18
    Join Date
    Mar 2003
    Location
    India {Mumbai};
    Posts
    3,871
    Originally posted by Andreas Masur

    AFAIK all these functions are implemented as either inline functions or macros therefore the overhead of a function call will be eliminated while compiling...
    Hey, what about MACROS? Do they reduce the size or calling stacks? Please not that macros are expanded by the PreProcessor every where they are placed in code. And this step is before compilation (and certainly before linking, deployment and execution of program).
    So macros doesnt REDUCE any comlpexities of this sort. They does only to coding level to the programmer.

    Lastly, again, using theApp is much better than AfxGetApp() if we are on same exe.
    My latest article: Explicating the new C++ standard (C++0x)

    Do rate the posts you find useful.

  4. #19
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by Ajay Vijay
    Hey, what about MACROS? Do they reduce the size or calling stacks? Please not that macros are expanded by the PreProcessor every where they are placed in code. And this step is before compilation (and certainly before linking, deployment and execution of program).
    So macros doesnt REDUCE any comlpexities of this sort. They does only to coding level to the programmer.

    Lastly, again, using theApp is much better than AfxGetApp() if we are on same exe.
    Well...that is basically what I was saying. Macros gets expanded before the compiling stage, inline functions gets expanded while compiling. If 'AfxGetApp()' is an inline function (which it is) it will be expanded into the code at compile time. Since the function basically only return 'theApp' there is not much difference after compiling between writing 'theApp' directly or using 'AfxGetApp()'.

    However, the whole thing is more a philosophical question rather than a technical one. Either one is fine, there is not much overhead so it comes down to a personal opinion.

    Since I tend to stich with the object-oriented way of thinking using a global variable is like a no-no for me...

  5. #20
    Join Date
    Mar 2003
    Location
    India {Mumbai};
    Posts
    3,871
    Is AfxGetApp not a voilation to OOP concept. Is it not a global one?
    My latest article: Explicating the new C++ standard (C++0x)

    Do rate the posts you find useful.

  6. #21
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by Ajay Vijay
    Is AfxGetApp not a voilation to OOP concept. Is it not a global one?
    Well...yes but it is at least an inline function...

  7. #22
    Join Date
    Mar 2003
    Location
    India {Mumbai};
    Posts
    3,871
    And also follows Encapsulation support of OOPS!
    My latest article: Explicating the new C++ standard (C++0x)

    Do rate the posts you find useful.

  8. #23
    Join Date
    May 1999
    Location
    DELAWARE, USA
    Posts
    9,917
    Some things to consider. Despite all OOP encapsulation and global variable awareness, famous theApp cannot be local.
    It is not simply a variable inserted by the wizard as proxima centaur mentioned in post. It is instantiation of one and only one object of the application class.

    After executable is invoked, kernel calls WinMainCRTStartup, part of MFC implementation in msvcr*.dll where after walk all pointer and initializes certain routines and eventually at the top it encounters pointer to an application’s constructor.

    theApp must be in global scope to be properly instantiated by call from MFC dll, besides at the time of app instantiation there is no other scope than global.
    Last edited by JohnCz; April 26th, 2003 at 09:36 PM.
    There are only 10 types of people in the world:
    Those who understand binary and those who do not.

  9. #24
    Xeon's Avatar
    Xeon is offline Want me to ban you?! Power Poster
    Join Date
    Jul 2000
    Location
    Singapore
    Posts
    4,195

    Talking

    Now, there's no reason to discuss over theApp or AfxGetApp() tio such an extent!

    The bottomline is : if you wanna be cute, use theApp. It's easier to type and it's cuter. Just ask the girls.

    Use AfxGetApp() when you're teaching newbie programmers how to program.

    Instead of :
    Code:
    HICON hIcon;
    hIcon = theApp.LoadIcon(IDI_GIRL);
    m_Static.SetIcon(hIcon);

    you can try :
    Code:
    m_Static.SetIcon(AfxGetApp()->LoadIcon(IDI_GIRL));
    This will :

    1) Boost your ego.
    2) Impress newbie and non-programmers.
    3) Get revered and worshipped.
    4) You win.
    "Hell is calling for you!" - Rufus, from Valkyrie Profile 2 : Silmeria

    "I'm getting tired of you devils.....finishing strike......Final Blast!" - Arngrim, from Valkyrie Profile 2 : Silmeria

  10. #25
    Join Date
    Mar 2003
    Location
    India {Mumbai};
    Posts
    3,871
    Ha Ha Ha
    My latest article: Explicating the new C++ standard (C++0x)

    Do rate the posts you find useful.

  11. #26
    Join Date
    Mar 2002
    Location
    St. Petersburg, Florida, USA
    Posts
    12,117

    Re: theApp vs. AfxGetApp() - does it matter?

    Quote Originally Posted by Andreas Masur View Post
    Well...that is the complete implementation of the function...however my intention was to keep things simplified to the OP and to show that there is basically no difference between using the function and/or 'theApp'...
    (17 years later)....

    There is a VERY real difference. It is physically possible to that multiple instances of theApp in different conditions (multiple DLLs', et. al.)... but AfxGetApp will always return the one registered as "afxCurrentWinApp"

    Now how THAT gets set........
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured