C++ callback function passed to a C program

Discussion in 'C++' started by Eric Entressangle, Jul 25, 2003.

  1. Hi all,

    is there any trouble setting an C++ static class method as callback
    function for a C program or library ?

    Thanks
    Eric Entressangle, Jul 25, 2003
    #1
    1. Advertising

  2. Eric Entressangle

    Rolf Magnus Guest

    Eric Entressangle wrote:

    > Hi all,
    >
    > is there any trouble setting an C++ static class method as callback
    > function for a C program or library ?


    Yes. The function will have C++ calling conventions, but be called using
    C calling conventions. An some (many?) compilers, they are both the
    same, but if they differ, it won't work. For maximum portability, you
    should only use extern "C" functions for that, which is of course not
    possible for member functions, even if static.
    Rolf Magnus, Jul 25, 2003
    #2
    1. Advertising

  3. On Fri, 25 Jul 2003 18:22:21 +0200, Rolf Magnus <> wrote:

    >Eric Entressangle wrote:
    >
    >> Hi all,
    >>
    >> is there any trouble setting an C++ static class method as callback
    >> function for a C program or library ?

    >
    >Yes. The function will have C++ calling conventions, but be called using
    >C calling conventions. An some (many?) compilers, they are both the
    >same, but if they differ, it won't work. For maximum portability, you
    >should only use extern "C" functions for that, which is of course not
    >possible for member functions, even if static.


    Using an 'extern "C"' function doesn't buy additional portability... ;-)

    Reason: neither C nor C++ defines the machine-level calling convention,
    nor name-mangling or other relevant things. With at least one of the
    most used C and C++ compilers 'extern "C"' has _no_ effect on the
    calling convention whatsoever. What it does influence with that
    compiler is the name mangling, i.e. linkage compatibility: the compiler
    trusts you to know what you're doing, since this spec removes type
    information (e.g. name mangling) in order to be linkage-compatible
    with C.

    The main assumption for the callback problem is calling convention
    compatibility, and linkage compatibility doesn't enter the picture, but
    the details of the calling convention compatibility depends on the
    compilers, and one should not assume that 'extern "C"' will influence
    calling conventions, data type compatibility, or any such thing.
    Alf P. Steinbach, Jul 25, 2003
    #3
  4. On Fri, 25 Jul 2003 19:54:33 +0200, Rolf Magnus <> wrote:

    >>
    >> Reason: neither C nor C++ defines the machine-level calling
    >> convention, nor name-mangling or other relevant things.

    >
    >I'm aware of that.


    Then you should draw the logical conclusions from that,



    [Silly and longish irrelevant quoting of the standard elided]
    >From the standard's POV,


    POV?


    >those things [calling convention, data types etc.] are all part
    >of the linkage.


    Even different versions of the same C++ compiler can produce
    incompatible object code, in full agreement with the standard.
    So in other words, what you write is not correct.



    >Anyway, what would you gain if your compiler use the correct naming for
    >the functions for calling them from C, if the data types aren't
    >compatible or the parameters are passed differently?


    You'd have to ask Kernighan and Ritchie about that... For in C you can
    have (or at least could have) incompatibility between calling code
    and called code even within the same compilation unit; hence the tendency
    of C programmers to write "int main(void)", because simply leaving out the
    argument list for a function would match any signature. When C++ is
    interfaced to C there is no way the C++ standard can compensate, and so
    it does not even try.

    On a more practical level it's _your_ job to make sure that everyhing
    matches between call and called function.

    Achieving linking is just one of many considerations, and furthermore,
    is not relevant to using a C++ function as a callback.
    Alf P. Steinbach, Jul 25, 2003
    #4
  5. Eric Entressangle

    Rolf Magnus Guest

    Alf P. Steinbach wrote:

    > On Fri, 25 Jul 2003 19:54:33 +0200, Rolf Magnus <>
    > wrote:
    >
    >>>
    >>> Reason: neither C nor C++ defines the machine-level calling
    >>> convention, nor name-mangling or other relevant things.

    >>
    >>I'm aware of that.

    >
    > Then you should draw the logical conclusions from that,
    >
    >
    >
    > [Silly and longish irrelevant quoting of the standard elided]
    >>From the standard's POV,

    >
    > POV?


    Point Of View

    >
    >
    >>those things [calling convention, data types etc.] are all part
    >>of the linkage.

    >
    > Even different versions of the same C++ compiler can produce
    > incompatible object code, in full agreement with the standard.
    > So in other words, what you write is not correct.


    But the part of the standard I quoted just says that.

    >>Anyway, what would you gain if your compiler use the correct naming
    >>for the functions for calling them from C, if the data types aren't
    >>compatible or the parameters are passed differently?

    >
    > You'd have to ask Kernighan and Ritchie about that... For in C you
    > can have (or at least could have) incompatibility between calling code
    > and called code even within the same compilation unit; hence the
    > tendency of C programmers to write "int main(void)", because simply
    > leaving out the argument list for a function would match any
    > signature.


    AFAIK, this is due to historical reasons. In C99, it's not true anymore.

    > When C++ is interfaced to C there is no way the C++ standard can
    > compensate, and so it does not even try.


    Well, it doesn't say how the linkage looks like, but it says that the
    compiler _must_ offer C linkage. Most C++ compilers also understand C
    or are bundled with a C compiler, and I would be quite surprised if
    they wouldn't just make their C linkage compatible with the C compiler.

    > On a more practical level it's _your_ job to make sure that everyhing
    > matches between call and called function.


    Well, it's "my" job to make sure that the compilers agree about their C
    linkage style.

    > Achieving linking is just one of many considerations, and furthermore,
    > is not relevant to using a C++ function as a callback.


    Look again at the OP's question. He asked about static members as
    callback for a C program or library. And so it definitely is relevant.
    That was my point anyway. I just answered that making the callback
    function extern "C" is the most portable solution. Do you disagree
    about that?
    Rolf Magnus, Jul 25, 2003
    #5
  6. On Fri, 25 Jul 2003 21:59:28 +0200, Rolf Magnus <> wrote:

    >Alf P. Steinbach wrote:
    >
    >> On Fri, 25 Jul 2003 19:54:33 +0200, Rolf Magnus <>
    >> wrote:
    >>
    >>>>
    >>>> Reason: neither C nor C++ defines the machine-level calling
    >>>> convention, nor name-mangling or other relevant things.
    >>>
    >>>I'm aware of that.

    >>
    >> Then you should draw the logical conclusions from that,
    >>
    >>
    >>
    >> [Silly and longish irrelevant quoting of the standard elided]
    >>>From the standard's POV,

    >>
    >> POV?

    >
    >Point Of View
    >
    >>
    >>
    >>>those things [calling convention, data types etc.] are all part
    >>>of the linkage.

    >>
    >> Even different versions of the same C++ compiler can produce
    >> incompatible object code, in full agreement with the standard.
    >> So in other words, what you write is not correct.

    >
    >But the part of the standard I quoted just says that.


    ???


    >>>Anyway, what would you gain if your compiler use the correct naming
    >>>for the functions for calling them from C, if the data types aren't
    >>>compatible or the parameters are passed differently?

    >>
    >> You'd have to ask Kernighan and Ritchie about that... For in C you
    >> can have (or at least could have) incompatibility between calling code
    >> and called code even within the same compilation unit; hence the
    >> tendency of C programmers to write "int main(void)", because simply
    >> leaving out the argument list for a function would match any
    >> signature.

    >
    >AFAIK, this is due to historical reasons. In C99, it's not true anymore.


    Keep in mind that the C++ standard stems from 1997, and that 1997 < 1999.



    >> When C++ is interfaced to C there is no way the C++ standard can
    >> compensate, and so it does not even try.

    >
    >Well, it doesn't say how the linkage looks like, but it says that the
    >compiler _must_ offer C linkage. Most C++ compilers also understand C
    >or are bundled with a C compiler, and I would be quite surprised if
    >they wouldn't just make their C linkage compatible with the C compiler.


    As a concrete example, Visual C++ supports a number of different
    calling conventions such as "__stdcall" (which oldtimers like me think
    of as Pascal) and "__cdecl" (which we think of as "C", purely because
    of typical usage). If you decorate a function with 'extern "C"',
    then (with this widely used compiler) that does _not_ affect the
    calling convention. It affects only the external name the linker sees
    (wrt. to the standard there's not necessarily a linker involved, but
    this scheme is, as far as I know, completely standard-conforming.)

    The crux is that there's no such thing as "the" C compiler.

    There are a number of different C compilers, and even using just one
    compiler you can compile functions that look the same to the linker
    (and so, no amount of fiddling in C++ can guarantee compatibility) but
    which have different calling conventions, different sizes of int, or
    whatever.




    >> On a more practical level it's _your_ job to make sure that everyhing
    >> matches between call and called function.

    >
    >Well, it's "my" job to make sure that the compilers agree about their C
    >linkage style.


    Yep.


    >> Achieving linking is just one of many considerations, and furthermore,
    >> is not relevant to using a C++ function as a callback.

    >
    >Look again at the OP's question. He asked about static members as
    >callback for a C program or library. And so it definitely is relevant.
    >That was my point anyway. I just answered that making the callback
    >function extern "C" is the most portable solution. Do you disagree
    >about that?


    Yep.
    Alf P. Steinbach, Jul 25, 2003
    #6
  7. Eric Entressangle

    Rolf Magnus Guest

    Alf P. Steinbach wrote:

    >>But the part of the standard I quoted just says that.

    >
    > ???


    I can repeat that quote again, though I don't know why you don't just
    read it in my previous posting. So again, I said:

    >>>> those things [calling convention, data types etc.] are all part
    >>>> of the linkage.


    And you said:

    >>> Even different versions of the same C++ compiler can produce
    >>> incompatible object code, in full agreement with the standard.


    to which I agree, but not to:

    >>> So in other words, what you write is not correct.


    I quoted the following sentence from the standard:

    All function types, function names and variable names have a language
    linkage. [Note: Some of the properties associated with an entity with
    language linkage may be associated with a particular form of
    representing names of objects and functions with external linkage, or
    with a particular calling convention, etc. ]

    It says that "a particular calling convetion, etc." is no less part of
    the "language linkage" than "a particular form of representing names of
    objects and functions with external linkage". That's what I said above
    and you claimed to be "not correct".

    Besides that, of course the code is not compatible with every C
    compiler, but from what I read from the standard (Every implementation
    shall provide for linkage to functions written in the C programming
    language, "C", and linkage to C++ functions, "C++".), there must be at
    least one C compiler that it's compatible with. How else would the
    compiler be able to "provide linkage to functions written in the C
    programming language"?

    >>> You'd have to ask Kernighan and Ritchie about that... For in C you
    >>> can have (or at least could have) incompatibility between calling
    >>> code and called code even within the same compilation unit; hence
    >>> the tendency of C programmers to write "int main(void)", because
    >>> simply leaving out the argument list for a function would match any
    >>> signature.

    >>
    >>AFAIK, this is due to historical reasons. In C99, it's not true
    >>anymore.

    >
    > Keep in mind that the C++ standard stems from 1997, and that 1997 <
    > 1999.


    What does that have to do with each other?

    >>> When C++ is interfaced to C there is no way the C++ standard can
    >>> compensate, and so it does not even try.

    >>
    >>Well, it doesn't say how the linkage looks like, but it says that the
    >>compiler _must_ offer C linkage. Most C++ compilers also understand C
    >>or are bundled with a C compiler, and I would be quite surprised if
    >>they wouldn't just make their C linkage compatible with the C
    >>compiler.

    >
    > As a concrete example, Visual C++ supports a number of different
    > calling conventions such as "__stdcall" (which oldtimers like me think
    > of as Pascal) and "__cdecl" (which we think of as "C", purely because
    > of typical usage). If you decorate a function with 'extern "C"',
    > then (with this widely used compiler) that does _not_ affect the
    > calling convention. It affects only the external name the linker sees
    > (wrt. to the standard there's not necessarily a linker involved, but
    > this scheme is, as far as I know, completely standard-conforming.)
    >
    > The crux is that there's no such thing as "the" C compiler.


    Yes, that seems to be a quality-of-implementation issue. But as I said,
    I'd expect from a C++ compiler that is bundled with a C compiler that
    by default both use the same C "language linkage", including calling
    conventions.

    > There are a number of different C compilers, and even using just one
    > compiler you can compile functions that look the same to the linker
    > (and so, no amount of fiddling in C++ can guarantee compatibility) but
    > which have different calling conventions, different sizes of int, or
    > whatever.


    Yes. What's your point?

    >>> Achieving linking is just one of many considerations, and
    >>> furthermore, is not relevant to using a C++ function as a callback.

    >>
    >>Look again at the OP's question. He asked about static members as
    >>callback for a C program or library. And so it definitely is relevant.
    >>That was my point anyway. I just answered that making the callback
    >>function extern "C" is the most portable solution. Do you disagree
    >>about that?

    >
    > Yep.


    Ok, so what would be more portable then?
    Rolf Magnus, Jul 25, 2003
    #7
    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. dee
    Replies:
    9
    Views:
    499
    Joseph Byrns
    Apr 15, 2005
  2. Anand
    Replies:
    2
    Views:
    893
    Anand
    Sep 11, 2003
  3. xz
    Replies:
    2
    Views:
    386
    James Kanze
    Mar 14, 2008
  4. waldek
    Replies:
    2
    Views:
    459
    waldek
    Jul 25, 2008
  5. waldek
    Replies:
    3
    Views:
    233
    waldek
    Jul 29, 2008
Loading...

Share This Page