|
Hi, everyone!
In a C style project, I think the advantage of a global static function
is its speed. But does it have any limitations? (Thread safety?)
If it does not have any limitations, I will define all of my global functions
and global variables as static.
Can anyone give me some advice of using global static function and global
static variable? Both advantage and limitations.
Thanks in advance,
George
|
|
|
|
|
George2 wrote:
advantage of global static function
is its speed
How do you know that?
From what I understand there is no difference in "C" whatsoever between global and static, except for linking.
In "C++" static is a tricky thing because of the order or instantiation etc for the variable. However "good" "C++" should not use global variables, or functions, so static is the only other way to go.
|
|
|
|
|
Thanks, AlexO buddy!
What is the difference between a static global function (variable) and
a non-static global function(variable) in your mind?
regards,
George
|
|
|
|
|
Terminology, terminology, terminology ...
In C, I have always seen "global" variables created in one of the source files and then all other source files that want access to that global variable use "extern". I have seen some people create those global variables in header files an use tricks with #define and #ifdef, but those end up being just tricks and overly complicate the simple concept that is being implemented.
As for functions, you can write a function and any source file can have access to that function as long as it includes the header file. Okay, go ahead, call these "global" functions.
In C, though, when you use "static" on a function or variable, this is supposed to mean that the function or variable is only visible within that single file.
Therefore, it would be impossible to have a "static global" function or variable, because to be "global" means everything can see it and to be "static" means it is only visible in the file where it is written.
Now, in C++, static functions and variables really belong to the "class" and not to the instantiations of the class. When dealing with "class" variables (as opposed to "member" variables) it also become difficult to think of these being "global." In C++, I have always seen "global" functions and variables to be declared outside of any class.
As for speed, I think this is a moot point, because those declarations affect visibility and access from other code elements and not the final implementation and conversion into executable code. An address of a function must still be known, obtained, and accessed regardless of whether the function is global, static, or something else.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
I was going to ask the same question myself. If there is a difference, with todays processors (pipelining) you probably will not see it at all.
As for threading there is no difference.
John
|
|
|
|
|
Thanks, John buddy!
Do you mean whether or not we add "static" before a function
in a C project has no difference at all?
What about cross-access about static function (variable) and non-static
function (variable)? Are they all legal?
regards,
George
|
|
|
|
|
David has the correct answer on this: http://www.codeproject.com/script/comments/forums.asp?msg=544541&forumid=1647&mode=all&userid=9241#xx544541xx[^]
I was just thinking about it in an optimization point of view and did not remember exactly what a static function in c was. My point is a lot of the old optimizations are unnecissary because of the way current processors work. At any one time many instructions are executing and if you can avoid branches most integer instructions take only one clock. My point is that worrying about something that can save you a few clocks on a machine that executes 4 billion clocks (2Ghz * 2 pipelines) in one second is pointless unless you are executint the function millions of times. If this is the case make the function inline..
John
|
|
|
|
|
The static keyword only affects the visibility of a function or variable - a static function/variable can only be used within the file in which it is defined. There is no difference in terms of speed. The only limitation is that you can't use them from multiple files. No function is thread-safe unless you make it so, by programming safely. static variables are no different to global variables in this respect - remember that static only affects which part of the program can access them. Once you compile the code, there is no different between using static and not using it.
Generally, using static is a good thing, because it provides more information about where the function is used - it helps maintenance programmers who may have to look at the code later, and tells them that the function/variable is only used within the one file.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Well done. Excellent description. Back in the day, we used to use statics to emulate the concept of Class privates. If you could visualize a single .c file being a class, then the functions(methods) that you would want to expose to the world (linker) would be regular functions and the ones that were private to the file (class) were declared as static. Typically, this allowed for a public interface with action methods and get/set methods, and a hidden implementation (statics).
On a historical note, the first CFront C++ preprocessor (there wasn't yet a compiler) basically used statics and structs and function pointers to create Objects.
If you think about it in this way, you could emulate OOP in standard C (how cool it was at the time, and god I feel old).
onwards and upwards...
|
|
|
|
|
|
If you really think about what a C++ compiler does and what a processor can execute, nothing has changed in the last 15 years! Sure, the C++ preprocessor allows you to write in a higher level of abstraction and the vtable lookup is built in to the compiler output (we used to have to write these by hand), but in the end, it is just ASM MOV, INC, ADD, SUB, LEA, CALL, JMP, LOOP, etc... all due to the backwards compatibility boat anchor.
onwards and upwards...
|
|
|
|
|
Exactly  . The compiler now implements some of what was done by hand before. Other than that, it's just the same (almost...  ).
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
In C a global static function (or variable) has local (module) scope: it is only accessable in the current module/source file, and there probaly is no speed advange when programing for Win32.
As for thread safety: I do not see any problems [I could be wrong].
Trust in the code Luke. Yea right!
|
|
|
|
|
Hi All,
I Need Help Regarding The Storing of Images in Oracle as
Blob Data Type Using MFC or Visual C++
|
|
|
|
|
|
Which message is send to an CRichEdit when SetWindowText() is called. I need to catch Messages send with SetWindowText()...
|
|
|
|
|
|
I tried to use WM_SETTEXT but i not very happy with that. I use the SetWindowText(...) method to display text from a function to my RichEdit. When I call five times SetWindowText only on WM_SETTEXT message arrives...
|
|
|
|
|
It sounds like the OS is queuing them up and sending them as one message. Perhaps you could explain your problem in more detail. It may just be that you are barking up the wrong tree!
|
|
|
|
|
Hi,
When I tried to debug every Opengl program (on Nvidia based Graphic cards) the visual C++ 6 jump
in the disassembly window even when I put breakpoints.
I tried with demo found in the Web and have the same problem.
In retail version, programs run fine.
Is it due to the non-debug DLL of opengl.
B->
|
|
|
|
|
kassad666 wrote:
Is it due to the non-debug DLL of opengl.
yes, these dlls of course do not contain symbols information.
~RaGE();
|
|
|
|
|
Any idea to overriding that problem?
Why MFC don't just make a call to the DLL and return?
Why does it show the disassembly window?
I think the problems begin with my new Geforce 4 card and the new drivers of Nvidia.
I don't remember having problem with Creative Geforce 2MX
B->
|
|
|
|
|
Anonymous wrote:
Any idea to overriding that problem?
Use the debug libs !! OpenGL is open sourced, you can get debug libs for debugging.
Anonymous wrote:
Why MFC don't just make a call to the DLL and return?
The debugger look for the symbols, and when it does not find it, open a window and ask for the location (which operation can be CANCELled). So if you can't provide debug infos (for examples in compiled dll) the debugger will simply go into the assembly code. What you can do is put a breakpoint after the function call, and hit F5 
Anonymous wrote:
I think the problems begin with my new Geforce 4 card and the new drivers of Nvidia.
I do not think this has something to do with the hardware (unless the operations you try to debug were done in the soft before, and is now handled directly by the nVidia chipset).
~RaGE();
|
|
|
|
|
Hi,
Has anybody used WM_PRINTCLIENT message?
I m using the following SendMessage call.....
SendMessage(hWnd, WM_PRINTCLIENT, (WPARAM) hDCMem, PRF_CLIENT | PRF_ERASEBKGND | PRF_CHILDREN );
but this returns a black window.
Any clues?
Thanks,
peenu.
|
|
|
|
|
peenu wrote:
Has anybody used WM_PRINTCLIENT message?
Yes, although I usually use WM_PRINT with the PRF_CLIENT flag. Not all window types support the WM_PRINTCLIENT message, or WM_PRINT for that matter.
I assume you're setting your memory DC up correctly - creating and selecting a bitmap for it, etc.
Your syntax is correct, so if your DC is setup correctly and it still doesn't work, then the window you're sending the message to probably doesn't handle the message, and there's not much you can do about it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
, so it's nice to know I got one right 
