extern inline

Discussion in 'C Programming' started by sinbad, Jul 16, 2009.

  1. sinbad

    sinbad Guest

    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
    sinbad, Jul 16, 2009
    #1
    1. Advertising

  2. "sinbad" <> wrote in message
    news:...
    > 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...).
    BGB / cr88192, Jul 16, 2009
    #2
    1. Advertising

  3. sinbad

    Mug Guest

    On Jul 16, 5:58 am, sinbad <> wrote:
    > 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
    Mug, Jul 16, 2009
    #3
  4. Mug <> writes:

    > On Jul 16, 5:58 am, sinbad <> wrote:
    >> 1.h
    >> ----
    >> extern inline void f() {
    >>   printf("extern inline fun called...");
    >>
    >> }

    <snip>
    > 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

    <snip>
    > 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.
    Ben Bacarisse, Jul 16, 2009
    #4
  5. sinbad <> writes:

    > 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:
    -------
    #include "f.h"
    /* use f() */
    -------

    f.c:
    ----
    #define inline /* nothing */
    #include f.h
    ----

    --
    Ben.
    Ben Bacarisse, Jul 16, 2009
    #5
  6. "Ben Bacarisse" <> wrote in message
    news:...
    > Mug <> writes:
    >
    >> On Jul 16, 5:58 am, sinbad <> wrote:
    >>> 1.h
    >>> ----
    >>> extern inline void f() {
    >>> printf("extern inline fun called...");
    >>>
    >>> }

    > <snip>
    >> 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
    >
    > <snip>
    >> 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.
    >


    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...


    > --
    > Ben.
    BGB / cr88192, Jul 16, 2009
    #6
  7. sinbad

    Flash Gordon Guest

    BGB / cr88192 wrote:

    <snip>

    > '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.
    --
    Flash Gordon
    Flash Gordon, Jul 16, 2009
    #7
  8. "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...
    > BGB / cr88192 wrote:
    >
    > <snip>
    >
    >> '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.
    >


    ok.


    >> 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.
    >


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


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

    >
    > 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...


    >> 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.


    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
    BGB / cr88192, Jul 16, 2009
    #8
  9. sinbad

    Flash Gordon Guest

    BGB / cr88192 wrote:
    > "Flash Gordon" <> wrote in message
    > news:-gordon.me.uk...
    >> BGB / cr88192 wrote:


    <snip>

    >>> 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.
    >>

    >
    > 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.

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

    >> 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"...


    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.

    >>> 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.

    >
    > 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.
    --
    Flash Gordon
    Flash Gordon, Jul 16, 2009
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Abhi
    Replies:
    2
    Views:
    725
    E. Robert Tisdale
    Jul 3, 2003
  2. Thomas Matthews
    Replies:
    5
    Views:
    2,372
    tom_usenet
    Aug 2, 2004
  3. evan

    extern inline

    evan, Mar 6, 2005, in forum: C Programming
    Replies:
    2
    Views:
    506
    Kevin Bracey
    Mar 7, 2005
  4. Sean
    Replies:
    4
    Views:
    660
    Rolf Magnus
    Apr 30, 2006
  5. Andre
    Replies:
    5
    Views:
    520
    Keith Thompson
    Jul 17, 2012
Loading...

Share This Page