I know what it means when declared in source file. I reading some code, find that static function in header files could be invoke in other files.
-
It will effectively create a separate static function with the same name inside every cpp file it is included into. The same applies to global variables.
-
Is the function defined in the header file? So that the actual code is given directly in the function, like this:
static int addTwo(int x) { return x + 2; }Then that's just a way of providing a useful function to many different C files. Each C file that includes the header will get its own definition that it can call. This of course wastes memory, and is (in my opinion) a quite ugly thing to be doing, since having executable code in a header is generally not a good idea.
Remember that #include:ing a header basically just pastes the contents of the header (and any other headers included by it) into the C file as seen by the compiler. The compiler never knows that the one particular function definition came from a header file.
quinmars : Well, the compiler will probably inline short functions. So it could actually use less memory, if the function is short enough. But I would prepend an "inline", so you don't get compile warnings about unused static functions. -
As others are saying, it has exactly the same meaning as a
staticfunction in the.cfile itself. This is because there is no semantic difference between.cand.hfiles; there is only the compilation unit made up of the file actually passed to the compiler (usually named.c) with the contents of any and all files named in#includelines (usually named.h) inserted into the stream as they are seen by the preprocessor.The convention that the C source is in a file named
.cand public declarations are in files named.his only a convention. But it is generally a good one. Under that convention, the only things that should appear in.hfiles are declarations so that you generally avoid having the same symbol defined more than once in a single program.In this particular case, the
statickeyword makes the symbol be private to the module, so there isn't a multiple-definition conflict waiting to cause trouble. So in that one sense, it is safe to do. But in the absence of a guarantee that the function would be inlined, you take the risk that the function would be instantiated in every module that happened to#includethat header file which at best is a waste of memory in the code segment.I am not certain of what use cases would justify doing this at all in a generally available public header.
If the
.hfile is generated code and only included in a single.cfile, then I would personally name the file something other than.hto emphasize that it isn't actually a public header at all. For example, a utility that converts a binary file into an initialized variable definition might write a file that is intended to be used via#includeand could very well contain astaticdeclaration of the variable, and possibly evenstaticdefinitions of accessor or other related utility functions. -
There is not semantic difference in defining in source file or header file, basically both means the same in plain C when using static keyword that, you are limiting the scope.
However, there is a problem in writing this in header file, this is because every time you include the header in a source file you'll have a copy of the function with same implementation which is much similar to have a normal function defined in header file. By adding the definition in header you are not achieving the what the static function is meant for.
Therefore, I suggest you should have your implementation only in your source file and not in header.
0 comments:
Post a Comment