extern inline

[sinbad]

1.h
----
extern inline void f() {
printf("extern inline fun called...");
}

1.c
---
#include "1.h"
int main() {
f();
return 0;
}

why does the above code throw this error.

/tmp/cc0unj2j.o(.text+0x1d): In function `main':
: undefined reference to `f'
collect2: ld returned 1 exit status

 

[BGB / cr88192]

1.h
----
extern inline void f() {
printf("extern inline fun called...");
}

1.c
---
#include "1.h"
int main() {
f();
return 0;
}

why does the above code throw this error.

/tmp/cc0unj2j.o(.text+0x1d): In function `main':
: undefined reference to `f'
collect2: ld returned 1 exit status

"extern inline" is a GCC'ism which I don't fully understand...

I think it means the compiler has the choice of using the inline version, or
using an external call...
in my compiler, I just sort of ignore the construct (pretending it is a
simple extern prototype instead...).

 

[Mug]

1.h
----
extern inline void f() {
  printf("extern inline fun called...");

}

1.c
---
#include "1.h"
int main() {
  f();
  return 0;

}

why does the above code throw this error.

/tmp/cc0unj2j.o(.text+0x1d): In function `main':
: undefined reference to `f'
collect2: ld returned 1 exit status

ok actually when you use the keyword extern it means the definition
is
declair somewhere else,so that's why the compiler ignore the fonction
definition
the correct way is :
extern.h:

#ifndef EXTERN_H
#define EXTERN_H
#include <stdio.h>
extern inline void f();
#endif

main.c

#include "extern.h"
void f() {
printf("extern inline fun called...\n");
}
int main()
{
f();
return 1;
}


and by the way,as far as i know,we never define a fonction in .h file.
i don't know so much how "inline" works,here's an article about it:
http://www.greenend.org.uk/rjk/2003/03/inline.html
i hope it will be helpfull.
Mug

 

[Ben Bacarisse]

ok actually when you use the keyword extern it means the definition
is
declair somewhere else,so that's why the compiler ignore the fonction
definition

No it doesn't. Putting extern on a normal (non-inline) function
definition has no effect at all.

the correct way is :

You suggested solution removed the key element. The OP wants an
inline definition.

extern.h:

#ifndef EXTERN_H
#define EXTERN_H

And names like this are reserved for use by the implementation (sad,
but true). A better pattern is:

#define H_EXTERN

and by the way,as far as i know,we never define a fonction in .h file.

You do if you want it to be inline, but one should (in general) use
static:

static inline void f() { ... }

The OP's extern inline definition acts as a declaration so the
implementation expects to find a definition of this name with external
linkage -- hence the error message. The OP may want the function to
available in this way (as a identifier with external linkage). In
that case they simply have to provide a non-inline definition like
they would for any such function.

 

[Ben Bacarisse]

1.h
----
extern inline void f() {
printf("extern inline fun called...");
}

1.c
---
#include "1.h"
int main() {
f();
return 0;
}

why does the above code throw this error.

/tmp/cc0unj2j.o(.text+0x1d): In function `main':
: undefined reference to `f'
collect2: ld returned 1 exit status

Your definition acts as an external declaration of f for which no
definition is found. If you don't need an external definition of f,
just replace "extern" with "static". If you do, you must provide one
by defining f without the inline keyword in some translation unit.

One way to do this is as follows:

f.h:
----
inline void f() { ... }
----

main.c:

 

[BGB / cr88192]

No it doesn't. Putting extern on a normal (non-inline) function
definition has no effect at all.


You suggested solution removed the key element. The OP wants an
inline definition.


And names like this are reserved for use by the implementation (sad,
but true). A better pattern is:

#define H_EXTERN



You do if you want it to be inline, but one should (in general) use
static:

static inline void f() { ... }

The OP's extern inline definition acts as a declaration so the
implementation expects to find a definition of this name with external
linkage -- hence the error message. The OP may want the function to
available in this way (as a identifier with external linkage). In
that case they simply have to provide a non-inline definition like
they would for any such function.

I think very possibly, the OP was trying for 'extern inline', which, it is
worth noting, occurs many places in certain GCC-specific headers...

however, in my compiler, it was reasonable to just ignore them, as they were
creating compiler difficulties...


'static inline' is probably better, but then one may find that certain
compilers (such as MSVC), do not correctly handle the inline keyword (MSVC
apparently expects parens, like "inline(...)" or similar...).

actually, MSVC has several annoyances:
they apparently "deprecate" most of the standard C library (you can use it,
but the compiler complains endlessly);
various standard C features (and especially C99 features) are absent;
....

but, as is, MSVC does have one advantage over GCC:
its current Win64 support is better.


(GCC now has Win64 support, but it is not very good as of yet, so I await a
time when it is improved...).

actually, as is, I am using MSVC and some GCC related tools at the same
time...

 

[Flash Gordon]

BGB / cr88192 wrote:

'static inline' is probably better, but then one may find that certain
compilers (such as MSVC), do not correctly handle the inline keyword (MSVC
apparently expects parens, like "inline(...)" or similar...).

If MSVC has inline at all in any form it is as an extension.

actually, MSVC has several annoyances:
they apparently "deprecate" most of the standard C library (you can use it,
but the compiler complains endlessly);

Set the flag to tell it not to.

various standard C features (and especially C99 features) are absent;
....

The *only* features missing are those specific to C99.

but, as is, MSVC does have one advantage over GCC:
its current Win64 support is better.

<snip>

From my experience MSVC is very good as a C90 compiler, and as a
compiler for targetting Windows.

 

[BGB / cr88192]

BGB / cr88192 wrote:



If MSVC has inline at all in any form it is as an extension.

ok.



Set the flag to tell it not to.

yep. there is a pragma, I have been using it...

The *only* features missing are those specific to C99.

yep, and they are, indeed, missing...

note that, more or less, what is C99 has become, to a large degree, "the
standard"...

it is an issue to have things like '_Complex' and 'va_copy' not work...

<snip>

From my experience MSVC is very good as a C90 compiler, and as a compiler
for targetting Windows.

yes, ok.

however, in a pure form C90 does not so much reflect "the state of C
development" anymore...

GCC, OTOH, has a decent portion of C99 support...


but, yes, it has good Win64 support, vs GCC's Win64 support which is still a
little shy of a production release in my tests...

 

[Flash Gordon]

yep. there is a pragma, I have been using it...

Last I checked there was a compiler switch, saves having to litter your
code with needless MS'isms.

yep, and they are, indeed, missing...

note that, more or less, what is C99 has become, to a large degree, "the
standard"...

There is officially no "more or less" about it, it is *the* standard.
It's just that the number of compilers to fully implement it is small,
and some have not even started.

it is an issue to have things like '_Complex' and 'va_copy' not work...

Yes, and I would be happier if MS has implemented C99.

yes, ok.

however, in a pure form C90 does not so much reflect "the state of C
development" anymore...

C90 still represents the most portable form of C.

GCC, OTOH, has a decent portion of C99 support...

Yes, but still not complete.

but, yes, it has good Win64 support, vs GCC's Win64 support which is still a
little shy of a production release in my tests...

It's not only the Win64 support which is good. There are all sorts of
other reasons I would (and have in the past) choose it for Windows
development.