extern as part of a function prototype

[blangela]

I am currently taking a course and one of the example programs showed
a function prototype something like:

extern void func();

I asked why the "extern" was necessary.

Someone in the class (not the instructor) explained that if the same
function prototype is used in more than one source file in a project,
that the linker will complain.

He explained to me that this was exactly the same as when you have a
global variable scoped in several source files, that where ever the
global variable is defined it does not need to be explicitly defined
as extern, but that in any other files that it needs to be in scope,
the global variable must be declared extern. This part I know to be
true from my own experience. It seemed to make sense, so I believed
him.

When I got back home I tried to verify what was stated above about
extern and function prototypes, but try as I might, using Visual
Studio Express 8, I could not generate any linking errors by leaving
out the extern keyword in function prototypes. BTW, I tried with both
a .c project (all the source files were .c files and I set the
compiler option to "Compile as C code" - the /TC option) and a .cpp
project (all the source files were .cpp files).

Can anyone give me an example where the extern keyword is actually
required? Or is Microsoft up to it's old tricks and "helping me"
without my knowledge and I would have had linking errors on other
IDEs ?

Bob

 

[blangela]

* blangela:












'extern' is the default for C++ function declarations, so ordinarily you do not
need it.

You need it only where it's not the default, and/or where you want to specify
"C" linkage.

An example where it's not default: the default for constants is internal
linkage, so if you declare a constant in a header file and define it in an
implementation file you need to use 'extern', like

<code file="x.h">
extern double const pi;
</code>

<code file="x.cpp">
#include "x.h"
double const pi = 3.14;
</code>

Thanks for your reply. If I undertand you correctly, the use of
extern as I explained it in my question is _NEVER_ necessary in a C++
application?

What about in a C application? Is the same answer true?

You mean compilers.

An IDE is not a compiler: it just gives you easy access to a compiler, and other
relevant tools.

To be honest, the reason I used IDE, was as a short cut for compiler
and linker, since I am not sure if it is the MS compiler or MS linker
that is the problem. Does that make sense?

Thanks again for your reply!

 

[James Kanze]

I am currently taking a course and one of the example programs
showed a function prototype something like:

extern void func();

I asked why the "extern" was necessary.

Someone in the class (not the instructor) explained that if
the same function prototype is used in more than one source
file in a project, that the linker will complain.

That's not strictly true. A function declaration that is not a
definition is implicitly "extern".

In theory, at least, it's probably better to be consistent, and
to use it. But there's so much code around that doesn't that
most programmers are used to not seeing it, so it isn't that
important. (Given the inconsistent rules concerning linkage in
C++, one could argue that you should always specify it. But of
course, people---myself included---don't.)

 

[Nick Keighley]

Thanks for your reply.  If I undertand you correctly, the use of
extern as I explained it in my question is _NEVER_ necessary in a C++
application?

What about in a C application?  Is the same answer true?

yes

<snip>

 

[blangela]

That's not strictly true.  A function declaration that is not a
definition is implicitly "extern".

In theory, at least, it's probably better to be consistent, and
to use it.  But there's so much code around that doesn't that
most programmers are used to not seeing it, so it isn't that
important.  (Given the inconsistent rules concerning linkage in
C++, one could argue that you should always specify it.  But of
course, people---myself included---don't.)

Does that mean that some compilers do need the explicit use of extern
for function prototypes?

Bob

 

[James Kanze]

* James Kanze:

A function declaration that is a definition is also "extern"
by default.

So it is. I don't know what I was thinking of. (Actually, I do
know what I was thinking of: of the old days, when you said
"global" to export a symbol, and "extern" to import it. But
that's not really relevant to C++, given as how it was
assembler, and pre-dated even C.)

I think you meant "by default", not "implicitly".

I think the two terms mean more or less the same thing in this
context. But I'm not really sure. (Not getting enough rest
these days to be sure of anything, really.)

All of the above with the understanding that we're not talking
about member functions in a local class, because a local class
doesn't formally have linkage as of the current standard, and
of course also that there hasn't been some previous
declaration of the function, which would have established the
linkage.

Yes. I took it for granted that we were really only talking
about functions at namespace scope. You can't apply extern to a
member function, since its visibility is that of the class
(which as you say, is also "extern", except for local classes).

 

[James Kanze]

Does that mean that some compilers do need the explicit use of
extern for function prototypes?

It means that no compiler needs it, ever.

As Alf has reminded me, in the case of functions, the function
name always has external linkage (to express it in terms of the
standard), unless you explicitly say otherwise (i.e. with
"static"). Because of this, the only real reason to use
"extern" with a function is in order to be (more or less)
orthogonal with how you'd handle a data declaration. Or to keep
old fogeys like me happy, who remember the old days when you had
to explicitly export and import any symbol that was supposed to
be visible in another translation unit.

 

[blangela]

It means that no compiler needs it, ever.

As Alf has reminded me, in the case of functions, the function
name always has external linkage (to express it in terms of the
standard), unless you explicitly say otherwise (i.e. with
"static").  Because of this, the only real reason to use
"extern" with a function is in order to be (more or less)
orthogonal with how you'd handle a data declaration.  Or to keep
old fogeys like me happy, who remember the old days when you had
to explicitly export and import any symbol that was supposed to
be visible in another translation unit.

When was this requiremnt removed? Was it a side effect of some larger
change?

Thanks,

Bob

 

[James Kanze]

When was this requiremnt removed?

When Kernighan and Richie invented C. The "old days" I was
talking about were before C, when most systems level programming
(and a lot of other programming) were still done in assembler.

I think that most linkers still work like this; that the object
file format contains a list of exported symbols (globals) and
their relative addresses, and a list of imported symbols
(externs), which have to be resolved. (That's the way linkers
worked when I worked on compilers, and I don't think that much
has changed since then. At least in the global philosophy;
today we do have weak symbols, and a few other additional
features.) But it's never been the case with C nor with C++.