Is there a real need to use keyword static with functions?

L

lcdgoncalves

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

I don't know if this is a trivial matter since the reserved word
exists. :)
Or it exists for some other purpose I can't figure out.

What did I have missed? :)

Thanks in advance for answers
 
I

Ian Collins

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?
Yes, otherwise the functions have global scope and pollute the global
namespace. You may not want to export those symbols and you, or the
user of you code, will run into link problems if the same name is used
in more than one source file.
 
B

Ben Pfaff

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Yes. If two functions are defined without static, but with the
same name, in different translation units, then the result is
undefined behavior. Using static avoids this undefined behavior.
 
C

christian.bau

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

That's sad.

Do you have a database of all functions in your programs to make sure
that you don't use the same function name twice?
 
K

Kenny McCormack

Yes. If two functions are defined without static, but with the
same name, in different translation units, then the result is
undefined behavior. Using static avoids this undefined behavior.

Again, you guys are "talking around the problem". What you should be
reacting to is the implication (i.e., the OP's delusion) that neglecting
to declare a prototype in a header file somehow "hides" global symbols
found in translation units. I.e., makes it as if they had been declared
(gasp!) static.

Well, to the OP, 'taint so.
 
U

user923005

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

I don't know if this is a trivial matter since the reserved word
exists. :)
Or it exists for some other purpose I can't figure out.

What did I have missed? :)

Thanks in advance for answers

Functions should always be made static if they are not intended as end-
user available routines.
Imagine some function called :
void HelperInitializer(struct goombah * foo);
and it is only supposed to be called by *you* the programmer. It is
to be called only once and if it were to be called again, it would
reset the state of some of your objects in a way not intended. It is
essential to define this function as static or it *will* be available
to the end-user of the library whether you like it or not.

There are lots of other sensible reasons for static (some of which are
mentioned else-thread).

The author of that book wouldn't have been Herbert Schildt, would it?
 
R

Richard Tobin

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Bear in mind that there's nothing magic about .h files. They're just
some C code - usually, but not necessarily declarations - that can be
handily included in other files. So the fact that a function isn't
declared in a .h file doesn't stop some other part of the program from
using it, or from inadvertently using the same name for something else
(which may be detected when you link the program, or may just cause
some peculiar failure later on).

-- Richard
 
E

Erik de Castro Lopo

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Not necessary, but good practice.

If you use static then you can have two C files which both have
their own definition of my_function and the compiler will accept
it and do the right thing.

If you don't use static you will get a link time error about two
definitions of my_function.

HTH,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Failure is not an option. It comes bundled with your Microsoft
product.
 
P

pradeep

Hi everyone,
Is there any real need for keyword "static inline" with
functions.

--pradeep.
 
S

santosh

pradeep wrote:

Please don't top-post. Your reply should be below or interspersed with
the material you quote. Irrelevant text can be deleted, particularly
sig blocks that follow a '-- ' marker.
[fixed]
Hi everyone,
Is there any real need for keyword "static inline" with
functions.

Well, static's effect has been explained in this thread. The inline
qualifier is a hint to the compiler to speed up access to the
function, if possible. Generally, it's used for very small functions
that're called in tight loops. The compiler may or may not actually
embed the function's body into each place where it's invoked. There
may be other methods of speeding up access to it.

inline is a C99 feature, unlike static.
 
S

santosh

pradeep said:
Hi everyone,
Is there any real need for keyword "static inline" with
functions.

BTW, using inline has many caveats that you need to be aware of.
From the working draft of ISO C Standard:

6.7.4 Function speciï¬ers
Syntax
1 function-speciï¬er:
inline
Constraints
2 Function speciï¬ers shall be used only in the declaration of an
identiï¬er for a function.
3 An inline deï¬nition of a function with external linkage shall not
contain a deï¬nition of a
modiï¬able object with static storage duration, and shall not contain
a reference to an
identiï¬er with internal linkage.
4 In a hosted environment, the inline function speciï¬er shall not
appear in a declaration
of main.
Semantics
5 A function declared with an inline function speciï¬er is an inline
function. The
function speciï¬er may appear more than once; the behavior is the
same as if it appeared
only once. Making a function an inline function suggests that calls
to the function be as
fast as possible.118) The extent to which such suggestions are
effective is
implementation-deï¬ned.119)
6 Any function with internal linkage can be an inline function. For a
function with external
linkage, the following restrictions apply: If a function is declared
with an inline
function speciï¬er, then it shall also be deï¬ned in the same
translation unit. If all of the
ï¬le scope declarations for a function in a translation unit include
the inline function
speciï¬er without extern, then the deï¬nition in that translation unit
is an inline
deï¬nition. An inline deï¬nition does not provide an external
deï¬nition for the function,
and does not forbid an external deï¬nition in another translation
unit. An inline deï¬nition
provides an alternative to an external deï¬nition, which a translator
may use to implement
any call to the function in the same translation unit. It is
unspeciï¬ed whether a call to the
function uses the inline deï¬nition or the external deï¬nition.120)
 
J

jaysome

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

I don't know if this is a trivial matter since the reserved word
exists. :)
Or it exists for some other purpose I can't figure out.

What did I have missed? :)

Thanks in advance for answers

In C, functions can have one of two types of linkage: external or
internal.

A function with external linkage can be defined only once and called
by multiple translation units, while a function with internal linkage
can be defined once for each translation unit and called (directly)
only by the translation unit that defines it (separate translation
units that define the same function with internal linkage effectively
get their own copy of the function definition).

The keyword static, when used in a function prototype or definition,
implies internal linkage, while the keyword extern (or lack of both
extern and static) in a function prototype or definition, implies
external linkage

All functions should have a prototype in scope, with the exception of
main().

Function prototypes declared in a .h file should not be declared as
static; you can declare them as extern, but that's not necessary.

/* foo.h */
static void foo1(void); /* bad */
void foo2(void); /* okay */
extern foo3(void); /* okay, though use of extern is superfluous */

Function prototypes declared in a .c file should use static. The
function definition whose prototype is declared with static can also
use static (but not extern), but that's not necessary, although it's
good practice.

/* foo.c */
static void foo4(void);

#ifdef DEFS_WITH_STATIC
static void foo4(void) /* okay */
{
/* implement foo4 */
}
#else
void foo4(void) /* okay */
{
/* implement foo4 */
}
#endif

Likewise, function definitions whose prototype is not declared with
static can also use extern (but not static), but that's not necessary,
although it's considered acceptable by some and suspect by others
(PC-lint falls into the latter category).

/* foo.c */
#include "foo.h"
#ifdef DEFS_WITH_EXTERN
extern void foo2(void) /* okay */
{
/* implement foo2 */
}
#else
void foo2(void) /* okay */
{
/* implement foo2 */
}
#endif

One argument for not using extern with function definitions is that
you can "grep" a .c source file for "extern" and expect to find no
matches.

Regards
 
C

CBFalconer

santosh said:
pradeep wrote:

Please don't top-post. Your reply should be below or interspersed
with the material you quote. Irrelevant text can be deleted,
particularly sig blocks that follow a '-- ' marker.
[fixed]
.... snip ...

IIRC he's been told this before, and ignored it. Unless there are
multiple pradeeps extant, he is due to be plonked.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
 
R

Roland Pibinger

Functions should always be made static if they are not intended as end-
user available routines.

IOW, static functions in C serve the same purpose as 'private'
funtions are in other languages.

Best wishes,
Roland Pibinger
 
S

santosh

Roland said:
IOW, static functions in C serve the same purpose as 'private'
funtions are in other languages.

Maybe in some senses of private. For example, C++'s private member
functions are quite different from C's static qualified functions.
 
L

lcdgoncalves

That's sad.

Do you have a database of all functions in your programs to make sure
that you don't use the same function name twice?

Dear Christian

Although it's clear for me now that "staticizing" functions avoids
exporting uncessessary symbols to linker, it's quite unlikely that one
can possibly duplicate a name of a temporary function.
Specially if one give good names for them, with a prefix in a way
similar to Gtk package and similars.

Anyway, I've learned the lesson. Tnx for the advice
 
L

lcdgoncalves

Functions should always be madestaticif they are not intended as end-
user available routines.
Imagine some function called :
void HelperInitializer(struct goombah * foo);
and it is only supposed to be called by *you* the programmer. It is
to be called only once and if it were to be called again, it would
reset the state of some of your objects in a way not intended. It is
essential to define this function asstaticor it *will* be available
to the end-user of the library whether you like it or not.

OK. I got it. It's clear to me now.
Thereare lots of other sensible reasons forstatic(some of which are
mentioned else-thread).

Yep. :)
The author of that book wouldn't have been Herbert Schildt, would it?

Well... it's time to study a little more. I have a copy of HS's book
somewhere. :) Perhaps I've missed something the first time I read it.

Thanks for your helpful hint. Regards
 
M

mark_bluemel

Well... it's time to study a little more. I have a copy of HS's book
somewhere. :) Perhaps I've missed something the first time I read it.

The recommendation from the group would probably be to ditch HS's book
- he's not regarded in great esteem round here...
 
C

Charlton Wilbur

l> Well... it's time to study a little more. I have a copy of HS's
l> book somewhere. :) Perhaps I've missed something the first time
l> I read it.

If you did, that can only be a good thing, as Herbert Schildt gets quite
a bit wrong. Your best bet is to burn that book and use a better one.

Charlton
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top