Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > static keyword

Reply
Thread Tools

static keyword

 
 
eryer
Guest
Posts: n/a
 
      01-07-2010
Hi,
i have a question about static function...for example:

file1.c
static void foo(void);
.....
void foo ()
{
...
}

in this example, optimizations due to static keyword at compiler time
are performed or not? Or is more correct do something like:

file1A.c
static void foo(void);
.....
static void foo ()
{
...
}

Thanks
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-07-2010
eryer wrote:
> Hi,
> i have a question about static function...for example:
>
> file1.c
> static void foo(void);
> .....
> void foo ()
> {
> ...
> }
>
> in this example, optimizations due to static keyword at compiler time
> are performed or not?


Such as? The static keyword simply tells the compiler not to export the
name; it is only visible in the compilation unit where it is declared.

> Or is more correct do something like:
>
> file1A.c
> static void foo(void);
> .....
> static void foo ()
> {
> ...
> }


It makes no difference.


--
Ian Collins
 
Reply With Quote
 
 
 
 
BGB / cr88192
Guest
Posts: n/a
 
      01-07-2010

"eryer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
> i have a question about static function...for example:
>
> file1.c
> static void foo(void);
> .....
> void foo ()
> {
> ...
> }
>
> in this example, optimizations due to static keyword at compiler time
> are performed or not? Or is more correct do something like:
>
> file1A.c
> static void foo(void);
> .....
> static void foo ()
> {
> ...
> }
>


IMO, it is better to have both declarations the same, as in the latter case.

that said, static defines semantics, not optimizations.
static on a function will essentially just hide it from other compilation
units, but typically little more than this.
this is the same semantics as for global variables.


any optimizations done, or not done, due to the use of static are compiler
dependent.
in most cases, there is unlikely to be much of any real difference though...

granted then, if you mean putting a static in a header, vs a non-static
function in another compilation unit, this does effect something: it may
allow the compiler to inline the function (the inline keyword may also serve
as a hint for it to do so as well, although not all compilers accept the
'inline' keyword).

however, in this case, the optimization would be due to the visability of
the function (it being in the same compilation unit, hence the compiler can
see its sourse), and not due to 'static', which in this case would serve
mostly to "hide" the function from other compilation units (such that you
can put the function in a header without risking the linker making a big
fuss and possibly refusing to link the program).

I have observed though that linkers may also silently "merge" all these
duplicate static functions (from headers), such that they don't take up lots
of extra space in the compiled output.

a similar observation is that the compiler may also omit the functions if
they are never called.


but, then again, all this is still due to the semantics, of the modifier,
rather than a result of the modifier itself.

for example, it is very well possible that a compiler will inline a function
even though it does not use any extra keywords, ...

and, it is also very well possible that a compiler will be stupid and not do
anything differently than simply obey the semantics of the keyword (IOW:
avoid a link-time error due to multiple-definition).


> Thanks
>



 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      01-10-2010
On Thu, 07 Jan 2010 14:56:42 -0800, eryer wrote:

> i have a question about static function...for example:
>
> file1.c
> static void foo(void);
> .....
> void foo ()
> {
> ...
> }
>
> in this example, optimizations due to static keyword at compiler time
> are performed or not?


Maybe.

Declaring the function "static" gives the compiler more scope for
optimisation, as it can determine exhaustively the contexts in which the
function may be called.

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-10-2010
Nobody wrote:
> On Thu, 07 Jan 2010 14:56:42 -0800, eryer wrote:
>
>> i have a question about static function...for example:
>>
>> file1.c
>> static void foo(void);
>> .....
>> void foo ()
>> {
>> ...
>> }
>>
>> in this example, optimizations due to static keyword at compiler time
>> are performed or not?

>
> Maybe.
>
> Declaring the function "static" gives the compiler more scope for
> optimisation, as it can determine exhaustively the contexts in which the
> function may be called.


This could allow it to take shortcuts on the calling conventions, it
might also encourage inlining, especially for a function which is ony
called once.
--
Flash Gordon
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-13-2010
Flash Gordon wrote:
> Nobody wrote:
>> Declaring the function "static" gives the compiler more scope for
>> optimisation, as it can determine exhaustively the contexts in which the
>> function may be called.

>
> This could allow it to take shortcuts on the calling conventions,


Interesting. For instance, a compiler for x86 might decide to forgo the
usual stack-based calling convention and use a register-based one, which
would be faster (assuming the number of arguments is reasonable). It
might also allow the compiler to skip saving some registers in the
calling function if it knows that the called function won't modify them.

However, does any compiler in the wild actually do this?

> it might also encourage inlining, especially for a function which is ony
> called once.


I suspect that, in general, compilers would either inline or not
regardless of the static designation.

I can see one way the heuristics might be affected, though. If the
called function validates its arguments, and the compiler can prove that
the validation has already been done (or explicit values set) by every
calling function, it may end up with a bunch of dead code that can be
eliminated, which in turn might drop the size below its heuristics'
threshold for inlining.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-13-2010
On 1/12/2010 10:44 PM, Stephen Sprunk wrote:
> Flash Gordon wrote:
>> Nobody wrote:
>>> Declaring the function "static" gives the compiler more scope for
>>> optimisation, as it can determine exhaustively the contexts in which the
>>> function may be called.

>>
>> This could allow it to take shortcuts on the calling conventions,

>
> Interesting. For instance, a compiler for x86 might decide to forgo the
> usual stack-based calling convention and use a register-based one, which
> would be faster (assuming the number of arguments is reasonable). It
> might also allow the compiler to skip saving some registers in the
> calling function if it knows that the called function won't modify them.
>
> However, does any compiler in the wild actually do this?


Dunno about that specific optimization, but there have
certainly been compilers that optimized `static' functions
differently than externally-linked ones. A <ctype.h> header
I once encountered contained *definitions* of toupper() and
the rest of the functions, all `static'. The accompanying
compiler would discard any that weren't used, and would try
to in-line those that were. This was, oh, fifteen or twenty
years ago, well before `inline' came into the language. (In
fact, the header was for the pre-ANSI VAXC compiler.)

If you formed a function pointer to isdigit(), say, and
passed it somewhere, the compiler would naturally compile a
free-standing (but still `static') isdigit() function. This
raised the possibility that two different translation units
could form isdigit() pointers that would compare unequal. I
don't know whether that possibility would violate anything in
the Standard; there was a discussion maybe twenty-five years
ago about whether `memcpy == memmove' was permissible, and IIRC
no satisfactory conclusion was ever reached.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      01-13-2010
Eric Sosman <(E-Mail Removed)> wrote:

> the Standard; there was a discussion maybe twenty-five years
> ago about whether `memcpy == memmove' was permissible, and IIRC
> no satisfactory conclusion was ever reached.


I can't see a reason why not.

Behaviour isn't a reason. memmove() has stricter requirements than
memcpy(), but in the cases where they differ, memcpy() has undefined
behaviour. If the outcome of that undefined behaviour happens to be
"behaves as if it were memmove()", that is certainly required.

Address _could_ be a reason, but I cannot find anything in the Standard
which demands that different functions have addresses that compare
differently. Nor, for that matter, can I find an explicit, blanket
demand that all objects' addresses must differ.
The difference between these cases is, of course, that objects can be
assigned to, and functions can be called. If you assign a value to one
object through a pointer, and that changes another object behind your
back, a conforming program will be able to notice. Therefore, assigning
to one object's address must not change what is at another object's; and
therefore, objects' addresses must be distinguishable.
Functions, though, are different. You can't assign to them; you can only
call them. When the only difference between two functions occurs when
there is undefined or implementation-defined behaviour, there is no
guarantee that any strictly conforming program can detect the difference
at all.
There is a parallel, by the way, in a specific type of object: string
literals. No strictly conforming program can assign a value to a string
literal; implementations can, and do, take advantage of this by merging
(partly) equal string literals, making their addresses identical or
making the address of one fall inside the other.

Put most illustratively, I would say that memmove == memcpy is
permissible for the same reason that "bcde" == "abcde"+1 is.

Richard
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-13-2010
On 1/13/2010 4:38 PM, Richard Bos wrote:
> Eric Sosman<(E-Mail Removed)> wrote:
>
>> the Standard; there was a discussion maybe twenty-five years
>> ago about whether `memcpy == memmove' was permissible, and IIRC
>> no satisfactory conclusion was ever reached.

>
> I can't see a reason why not.
>
> Behaviour isn't a reason. memmove() has stricter requirements than
> memcpy(), but in the cases where they differ, memcpy() has undefined
> behaviour. If the outcome of that undefined behaviour happens to be
> "behaves as if it were memmove()", that is certainly required.
>[...]


That's the gist of the argument as I recall it. Others
didn't buy it, and the discussion raged back and forth for no
few exchanges before sort of petering out. Early-to-middle
1990's, IIRC, should anyone want to excavate the ruins.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      01-14-2010
Richard Bos <(E-Mail Removed)> wrote:
>
> Address _could_ be a reason, but I cannot find anything in the Standard
> which demands that different functions have addresses that compare
> differently. Nor, for that matter, can I find an explicit, blanket
> demand that all objects' addresses must differ.


6.5.9p6:

Two pointers compare equal if and only if both are null
pointers, both are pointers to the same object (including a
pointer to an object and a subobject at its beginning) or
function...

Different objects are not "the same object", nor are different functions
"the same function".
--
Larry Jones

Somebody's always running my life. I never get to do what I want to do.
-- Calvin
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
put static keyword inside the JSP scripplets error Matt Java 3 03-15-2012 10:10 AM
RE: keyword checker - keyword.kwlist Hamilton, William Python 4 05-13-2007 06:31 AM
keyword checker - keyword.kwlist tom@finland.com Python 6 05-10-2007 04:53 PM
Static keyword usage in asp.net? =?Utf-8?B?RGF2ZQ==?= ASP .Net 11 11-29-2005 07:11 PM
static keyword inside member function cppaddict C++ 2 05-02-2004 07:09 PM



Advertisments