call c++ function from c

Discussion in 'C Programming' started by falk.von.roetel@web.de, Aug 9, 2007.

  1. Guest

    Hello,

    I have the problem to call a c++ funtion in a C project. I have a
    header file from the cpp file. In the header file the function is
    decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    in the c file and call the function GetHostIPAddresses(1);. But the
    linker doesn't found the function. Can someone give me a hint what is
    wrong.

    Best regards

    Falk
     
    , Aug 9, 2007
    #1
    1. Advertising

  2. wrote:
    > I have the problem to call a c++ funtion in a C project. I have a
    > header file from the cpp file. In the header file the function is
    > decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    > in the c file and call the function GetHostIPAddresses(1);. But the
    > linker doesn't found the function. Can someone give me a hint what is
    > wrong.


    It probably would be better to ask this in a comp.lang.c++ since
    this is more in the territory of expertise of the regulars over
    there. See also

    http://www.parashift.com/c -faq/mixing-c-and-cpp.html

    I try a short explanation anyway (which might be wrong since I
    am not a C++ expert!): In C++ you can have several functons with
    the same name that are only distinguished by the number and
    types of their arguments. To allow the linker to distinuish be-
    tween these functions the compiler renames the functions auto-
    matically, typically by appending some text to the names that
    indicates the number and types of arguments, like

    foo( int ) becomes foo_i
    foo( double ) becomes foo_d

    (this is an example, not the real thing, different C++ compilers
    may do it in different ways). If you know this mangled name then
    you can change the call of the function accordingly, i.e. use the
    mangled name in the C code. The obvious drawback is that this
    only works for the C++ compiler you determined for how it does
    the name mangling.

    If you can change the C++ source and there's only a single
    function with that name then you can declare it in the C++
    header file with

    extern "C" void f(int i, char c, float x);

    to keep the C++ compiler from mangling the function name.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Aug 9, 2007
    #2
    1. Advertising

  3. CBFalconer Guest

    wrote:
    >
    > I have the problem to call a c++ funtion in a C project. I have a
    > header file from the cpp file. In the header file the function is
    > decleared "int GetHostIPAddresses(ini i);". I inlcude the header
    > file in the c file and call the function GetHostIPAddresses(1);.
    > But the linker doesn't found the function. Can someone give me a
    > hint what is wrong.


    You can't do it. C++ has provisions for calling C functions, but C
    doesn't know anything about C++. Even the C++ calling is
    restricted to the same compiler.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 9, 2007
    #3
  4. <> wrote in message
    news:...
    > Hello,
    >
    > I have the problem to call a c++ funtion in a C project. I have a
    > header file from the cpp file. In the header file the function is
    > decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    > in the c file and call the function GetHostIPAddresses(1);. But the
    > linker doesn't found the function. Can someone give me a hint what is
    > wrong.
    >

    Get the C++ object file and dump it as ascii. You should see all the
    functions arrayed, but because it is C++ they have funny characters and
    other things associated with them.
    Extract the name - which may take two or three attempts - put it in your C
    source, and try to link. Eventually you will succeed. Then test the function
    carefully to make sure C++ isn't passing it any extra arguments.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Aug 9, 2007
    #4
  5. "Malcolm McLean" <> writes:
    > <> wrote in message
    > news:...
    >> I have the problem to call a c++ funtion in a C project. I have a
    >> header file from the cpp file. In the header file the function is
    >> decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    >> in the c file and call the function GetHostIPAddresses(1);. But the
    >> linker doesn't found the function. Can someone give me a hint what is
    >> wrong.
    >>

    > Get the C++ object file and dump it as ascii. You should see all the
    > functions arrayed, but because it is C++ they have funny characters
    > and other things associated with them.
    > Extract the name - which may take two or three attempts - put it in
    > your C source, and try to link. Eventually you will succeed. Then test
    > the function carefully to make sure C++ isn't passing it any extra
    > arguments.


    In other words, proceed by trial and error to produce code that's
    going to be horribly non-portable because it depends intimately on how
    the particular C++ compiler performs "name mangling".

    A much better idea: read section 32 of the "C++ FAQ Lite" at
    <http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html>, and
    take any further questions to comp.lang.c++.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 9, 2007
    #5
  6. wrote:
    > Hello,
    >
    > I have the problem to call a c++ funtion in a C project. I have a
    > header file from the cpp file. In the header file the function is
    > decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    > in the c file and call the function GetHostIPAddresses(1);. But the
    > linker doesn't found the function. Can someone give me a hint what is
    > wrong.


    Well, other explaind why it doesn't work pretty well, so I'll skip this
    part.
    If you want to use C++ function in C and you don't want to change C++
    code, add a wrapper layer. Decalre function in C++ that calls your
    intended function- it should look something like this:

    foo() - your C++ function.

    In .cpp file:
    extern "C" foo_for_C()
    { return foo()}

    In .h file:
    #ifdef __cplusplus
    extern "C" {
    #endif
    foo_for_c();

    #ifdef __cplusplus
    }
    #endif


    M.
     
    Marcin Wolcendorf, Aug 10, 2007
    #6
  7. Bill Reid Guest

    Marcin Wolcendorf <> wrote in message
    news:f9ho4k$lce$...
    > wrote:
    > >
    > > I have the problem to call a c++ funtion in a C project. I have a
    > > header file from the cpp file. In the header file the function is
    > > decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
    > > in the c file and call the function GetHostIPAddresses(1);. But the
    > > linker doesn't found the function. Can someone give me a hint what is
    > > wrong.

    >
    > Well, other explaind why it doesn't work pretty well, so I'll skip this
    > part.
    > If you want to use C++ function in C and you don't want to change C++
    > code, add a wrapper layer. Decalre function in C++ that calls your
    > intended function- it should look something like this:
    >
    > foo() - your C++ function.
    >
    > In .cpp file:
    > extern "C" foo_for_C()
    > { return foo()}
    >
    > In .h file:
    > #ifdef __cplusplus
    > extern "C" {
    > #endif
    > foo_for_c();
    >
    > #ifdef __cplusplus
    > }
    > #endif


    Well, looky there, an actual correct answer in this newsgroup. This
    question has come up several times here, and certain people have once
    again chosen to not only be presumably off-topic but just completely
    wrong as well. They were affirmatively corrected several times
    before, but apparently they are uneducable.

    And I'm quite sure, quite worthless as programmers or for any
    type of positive contribution to the human race. They are the garbage
    that lie to get a job, then dog it for as long as they can with a constant
    stream of excuses, lies, abuse, and obnoxious behavior in lieu of
    actually ever writing any type of useful software.

    In other words, the epitomy of how most employers are forced
    to view "software engineers" due to long painful experience...

    ---
    William Ernest Reid
     
    Bill Reid, Aug 11, 2007
    #7
  8. Chris Torek Guest

    >> wrote:
    >>>I have the problem to call a c++ funtion in a C project. ...


    >Marcin Wolcendorf <> wrote in message
    >news:f9ho4k$lce$...
    >> Well, other explaind why it doesn't work pretty well, so I'll skip this
    >> part.
    >> If you want to use C++ function in C and you don't want to change C++
    >> code, add a wrapper [via C++'s extern "C" method]. [example snipped]


    In article <707vi.416238$>,
    Bill Reid <> wrote:
    >Well, looky there, an actual correct answer in this newsgroup.


    Yes, except for one problem: the example code (that I snipped,
    above) is wrong. The bug is small and simple and easily corrected
    (and will be caught by the compiler), but still, the example contains
    a bug.

    (In fact, the C part of the example is valid C89 but not valid C99.
    This is, in effect, what is wrong with the C++ part of the example.)

    >This question has come up several times here ...


    And the answer here is "C++ defines a way to call C but not vice
    versa, so you will get a better (peer-reviewed, as it were) answer
    in comp.lang.c++, so you would be wiser to go there for advice."

    >... and certain people have once again chosen to not only be
    >presumably off-topic but just completely wrong as well.


    No, you and Marcin Wolcendorf were only *slightly* wrong. :)

    This sort of subtle error is *why* one should seek answers in a
    more-appropriate forum. A newsgroup full of POSIX-specializing
    programmers (such as comp.unix.programmer) is more likely to know
    all the details of, say, using POSIX AIO -- even from C code --
    than is a forum of "strictly ANSI/ISO C programmers" like the
    comp.lang.c newsgroup.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Aug 11, 2007
    #8
  9. Chris Torek <> wrote:
    > >> wrote:
    > >>>I have the problem to call a c++ funtion in a C project. ...

    >
    > >Marcin Wolcendorf <> wrote in message
    > >news:f9ho4k$lce$...
    > >> Well, other explaind why it doesn't work pretty well, so I'll skip this
    > >> part.
    > >> If you want to use C++ function in C and you don't want to change C++
    > >> code, add a wrapper [via C++'s extern "C" method]. [example snipped]

    >
    > In article <707vi.416238$>,
    > Bill Reid <> wrote:
    > >Well, looky there, an actual correct answer in this newsgroup.

    >
    > Yes, except for one problem: the example code (that I snipped,
    > above) is wrong. The bug is small and simple and easily corrected
    > (and will be caught by the compiler), but still, the example contains
    > a bug.
    >
    > (In fact, the C part of the example is valid C89 but not valid C99.
    > This is, in effect, what is wrong with the C++ part of the example.)


    I should have written 'foo(....)', so you wouldn't be confused. Well, I
    assumed, possibly wrongly, that 'looks something like that' is an
    example that might not compile, but shows a concept. Perahaps I should
    have put it in the footnote...

    >
    > >This question has come up several times here ...

    >
    > And the answer here is "C++ defines a way to call C but not vice
    > versa, so you will get a better (peer-reviewed, as it were) answer
    > in comp.lang.c++, so you would be wiser to go there for advice."
    >
    > >... and certain people have once again chosen to not only be
    > >presumably off-topic but just completely wrong as well.

    >
    > No, you and Marcin Wolcendorf were only *slightly* wrong. :)
    >
    > This sort of subtle error is *why* one should seek answers in a
    > more-appropriate forum. A newsgroup full of POSIX-specializing
    > programmers (such as comp.unix.programmer) is more likely to know
    > all the details of, say, using POSIX AIO -- even from C code --
    > than is a forum of "strictly ANSI/ISO C programmers" like the
    > comp.lang.c newsgroup.
    >


    Have you actually read the description of this newsgroup? It's nice and
    clear, one line only:
    'Disscussion about C.'
    I can't see here any 'strictly' nor 'ANSI' nor 'ISO'. The 'programmers'
    have also been lost somehere in translation... The only match is 'C'.
    Where *exactly* have you taken the description of this group from?


    Regards,

    M.W.
     
    Marcin Wolcendorf, Aug 14, 2007
    #9
  10. CBFalconer Guest

    Marcin Wolcendorf wrote:
    >

    .... snip ...
    >
    > Have you actually read the description of this newsgroup? It's
    > nice and clear, one line only:
    > 'Disscussion about C.'
    > I can't see here any 'strictly' nor 'ANSI' nor 'ISO'. The
    > 'programmers' have also been lost somehere in translation...
    > The only match is 'C'. Where *exactly* have you taken the
    > description of this group from?


    The only factual descriptions of the C language are the ISO
    standard(s) and, earlier, K & R.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 15, 2007
    #10
  11. Sudhanshu Guest

    header.h file
    #ifdef__cplusplus
    extern "C" {
    #endif
    int GetHostIPAddresses(ini i);
    #ifdef__cplusplus
    }
    #endif

    cpluplus.cpp
    #include <header.h>
    int GetHostIPAddresses(ini i)
    {
    ......
    }

    cfile.c
    #include <header.h>
     
    Sudhanshu, Aug 15, 2007
    #11
  12. CBFalconer Guest

    Sudhanshu wrote:
    >
    > header.h file
    > #ifdef__cplusplus
    > extern "C" {
    > #endif
    > int GetHostIPAddresses(ini i);
    > #ifdef__cplusplus
    > }
    > #endif
    >
    > cpluplus.cpp
    > #include <header.h>
    > int GetHostIPAddresses(ini i)
    > {
    > .....
    > }
    >
    > cfile.c
    > #include <header.h>


    That enables C++ to call C, not the reverse direction.

    Include adequate quotation from whatever you are answering, and
    indent your code properly. Don't use tabs, use spaces.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 16, 2007
    #12
  13. Chris Torek Guest

    In article <>,
    CBFalconer <> wrote:
    >[Using C++'s extern "C" construct] enables C++ to call C, not
    >the reverse direction.


    Actually, it works both ways, provided some reasonably obvious
    and straightforward restrictions are met.

    (It is possible to write C++ code that can*not* call C code, nor
    vice versa; and mixing one vendor's C compiler with another's C++
    compiler can result in various disasters, but this is equally true
    for mixing one vendor's C compiler with another vendor's C compiler.
    But if the calls can be done at all, the C++ extern "C" method is
    almost always the way to go. Further discussion about this really
    belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
    course.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Aug 16, 2007
    #13
  14. Chris Torek Guest

    Background: Marcin Wolcendorf provided a mostly-correct and suitably
    worded answer, to which I did not object. Then:

    >>In article <707vi.416238$>
    >>Bill Reid <> wrote:
    >>>Well, looky there, an actual correct answer in this newsgroup.


    >Chris Torek <> wrote:
    >> Yes, except for one problem: the example code (that I snipped,
    >> above) is wrong. The bug is small and simple and easily corrected
    >> (and will be caught by the compiler), but still, the example contains
    >> a bug.
    >>
    >> (In fact, the C part of the example is valid C89 but not valid C99.
    >> This is, in effect, what is wrong with the C++ part of the example.)


    In article <f9t46r$adm$>,
    Marcin Wolcendorf <> wrote:
    >I should have written 'foo(....)', so you wouldn't be confused. Well, I
    >assumed, possibly wrongly, that 'looks something like that' is an
    >example that might not compile, but shows a concept.


    Yes -- this was, I think, the main reason I did not object at all
    to your own posting. I was really responding to Bill Reid:

    >> This sort of subtle error is *why* one should seek answers in a
    >> more-appropriate forum. A newsgroup full of POSIX-specializing
    >> programmers (such as comp.unix.programmer) is more likely to know
    >> all the details of, say, using POSIX AIO -- even from C code --
    >> than is a forum of "strictly ANSI/ISO C programmers" like the
    >> comp.lang.c newsgroup.


    >Have you actually read the description of this newsgroup? It's nice and
    >clear, one line only:
    >'Disscussion about C.'
    >I can't see here any 'strictly' nor 'ANSI' nor 'ISO'.


    The lack of anything more specific -- the generality of the phrase
    "discussion about C" -- is precisely what creates this constraint!
    In a group that addresses generic "C" -- not "C on Tandem Non-Stop",
    not "C on VMS", not "the C routines provided by vxWorks" -- what
    sort of advice will you get on when to use semBCreate() versus
    semMCreate()? Who will tell you, correctly, all the details about
    SYS$QIO? Will you get correct information about thread programming
    here, or are you more likely to get correct information elsewhere?

    Perhaps you think we *should* discuss these here. But then I would
    have to wonder why we have comp.os.vms and comp.programming.threads.

    (Incidentally, one should use semBCreate if the mutex will be used
    for interrupt code. One should use semMCreate if the mutex needs
    to do automatic priority elevation to avoid inversions, or to set
    various options. Otherwise either one will generally suffice.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Aug 16, 2007
    #14
  15. CBFalconer Guest

    Chris Torek wrote:
    > CBFalconer <> wrote:
    >
    >> [Using C++'s extern "C" construct] enables C++ to call C, not
    >> the reverse direction.

    >
    > Actually, it works both ways, provided some reasonably obvious
    > and straightforward restrictions are met.
    >
    > (It is possible to write C++ code that can*not* call C code, nor
    > vice versa; and mixing one vendor's C compiler with another's C++
    > compiler can result in various disasters, but this is equally true
    > for mixing one vendor's C compiler with another vendor's C compiler.
    > But if the calls can be done at all, the C++ extern "C" method is
    > almost always the way to go. Further discussion about this really
    > belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
    > course.)


    The C++ system attempts to adorn external calls with information
    about parameters, etc. in various ways. The C system has no way of
    understanding this mess. Thus C can't call C++ bcause the
    'adornments' are missing. However, C++ has a provision for
    dropping those 'adornments' to call precompiled C code.

    Since C provision for linking to C++ only involves a couple of one
    line #includes, and no effort at the C++ level, I consider it
    discussable here. C99 includes the reserved identifier
    __cplusplus__ to guard those #includes.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 16, 2007
    #15
  16. Ian Collins Guest

    CBFalconer wrote:
    > Chris Torek wrote:
    >> CBFalconer <> wrote:
    >>
    >>> [Using C++'s extern "C" construct] enables C++ to call C, not
    >>> the reverse direction.

    >> Actually, it works both ways, provided some reasonably obvious
    >> and straightforward restrictions are met.
    >>
    >> (It is possible to write C++ code that can*not* call C code, nor
    >> vice versa; and mixing one vendor's C compiler with another's C++
    >> compiler can result in various disasters, but this is equally true
    >> for mixing one vendor's C compiler with another vendor's C compiler.
    >> But if the calls can be done at all, the C++ extern "C" method is
    >> almost always the way to go. Further discussion about this really
    >> belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
    >> course.)

    >
    > The C++ system attempts to adorn external calls with information
    > about parameters, etc. in various ways. The C system has no way of
    > understanding this mess. Thus C can't call C++ bcause the
    > 'adornments' are missing. However, C++ has a provision for
    > dropping those 'adornments' to call precompiled C code.
    >

    I think you are completely missing the point about it working both ways,
    never mind.

    --
    Ian Collins.
     
    Ian Collins, Aug 16, 2007
    #16
  17. SM Ryan Guest

    CBFalconer <> wrote:

    # understanding this mess. Thus C can't call C++ bcause the
    # 'adornments' are missing. However, C++ has a provision for

    That comes as a shock and disappointment to all of us who
    actually do this.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    If you plan to shoplift, let us know.
    Thanks
     
    SM Ryan, Aug 16, 2007
    #17
  18. Richard Guest

    SM Ryan <> writes:

    > CBFalconer <> wrote:
    >
    > # understanding this mess. Thus C can't call C++ bcause the
    > # 'adornments' are missing. However, C++ has a provision for
    >
    > That comes as a shock and disappointment to all of us who
    > actually do this.


    http://developers.sun.com/sunstudio/articles/mixing.html
     
    Richard, Aug 16, 2007
    #18
  19. Hi Chris,



    Chris Torek <> wrote:
    > Background: Marcin Wolcendorf provided a mostly-correct and suitably
    > > worded answer, to which I did not object. Then:
    > > >
    > > >


    ...snip..

    To make it short:
    - Please, if you add some criticism- be specific. I'd be happy if you
    pointed out mistakes I made. I guess this is what you object to do for
    philosophic reasons. Well, I have no solution to that, then; I need
    facts, not foggy clues and riddles anyway.
    - I can see your point of limiting the topics to 'C only'; I somewhat
    agree. Nevertheless making group too narrow will make it unusable
    (IMHO). Some other groups may do the same- then someone looking for
    answers will be bounced from every group with 'OT' excuse. IMO- this
    is the place to provide answers, not frustration. What's more- if
    you'll make it too strict, too narrow, you'll soon find there is
    no-one to talk to.


    Regards (and EOT),

    M.W.
     
    Marcin Wolcendorf, Aug 18, 2007
    #19
  20. Marcin Wolcendorf said:

    <snip>

    > - I can see your point of limiting the topics to 'C only'; I somewhat
    > agree.


    Good.

    > Nevertheless making group too narrow will make it unusable


    So will making it too wide. This newsgroup discusses C. That is a wide
    enough topic to ensure that this group has been useful for almost a
    quarter of a century.

    > (IMHO). Some other groups may do the same- then someone looking for
    > answers will be bounced from every group with 'OT' excuse. IMO- this
    > is the place to provide answers, not frustration.


    Right - and the answer to your question is that C does not provide a
    mechanism to interface specifically with C++ functions. If you find the
    answer frustrating, that's unfortunate, but it happens to be the
    correct answer nonetheless.

    > What's more- if
    > you'll make it too strict, too narrow, you'll soon find there is
    > no-one to talk to.


    And if you make it too wide, you'll soon find there's nowhere left to
    ask about C, because the S/N ratio will drop through the floor and the
    C experts will give up bothering with the group, so the only people
    left to answer your questions will be the guessers.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Aug 18, 2007
    #20
    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. grbgooglefan
    Replies:
    2
    Views:
    449
    Pascal Bourguignon
    Jan 30, 2008
  2. grbgooglefan
    Replies:
    4
    Views:
    465
    Kenny McCormack
    Jan 30, 2008
  3. grbgooglefan
    Replies:
    0
    Views:
    416
    grbgooglefan
    Jan 30, 2008
  4. Alok
    Replies:
    3
    Views:
    279
  5. THAKUR PRASHANT SINGH

    Class Function call vs Normal Function call

    THAKUR PRASHANT SINGH, Feb 26, 2010, in forum: Ruby
    Replies:
    7
    Views:
    211
    THAKUR PRASHANT SINGH
    Feb 27, 2010
Loading...

Share This Page