-
April 22nd, 2003, 08:44 AM
#16
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...
-
April 22nd, 2003, 09:15 AM
#17
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
-
April 25th, 2003, 03:29 AM
#18
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.
-
April 25th, 2003, 04:00 AM
#19
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...
-
April 25th, 2003, 04:49 AM
#20
Is AfxGetApp not a voilation to OOP concept. Is it not a global one?
-
April 25th, 2003, 05:50 AM
#21
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...
-
April 26th, 2003, 10:26 AM
#22
And also follows Encapsulation support of OOPS!
-
April 26th, 2003, 01:29 PM
#23
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.
-
April 26th, 2003, 08:59 PM
#24
"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
-
April 28th, 2003, 01:22 AM
#25
-
January 13th, 2021, 11:07 AM
#26
Re: theApp vs. AfxGetApp() - does it matter?
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|