Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #81161 > unrolled thread

Can extern "C" functions throw exceptions

Back to article view | Back to comp.lang.c++

Contents

  Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 12:35 +0200
    Re: Can extern "C" functions throw exceptions Bo Persson <bo@bo-persson.se> - 2021-09-11 13:49 +0200
      Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 13:57 +0200
      Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-11 15:19 +0300
      Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:32 +0200
      Re: Can extern "C" functions throw exceptions HorseyWorsey@the_stables.com - 2021-09-11 15:54 +0000
    Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 13:55 +0200
      Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:34 +0200
        Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:58 +0200
        Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 17:00 +0200
          Re: Can extern "C" functions throw exceptions "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-06 13:36 -0700
            Re: Can extern "C" functions throw exceptions Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 20:42 +0000
              Re: Can extern "C" functions throw exceptions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 16:12 -0700
                Re: Can extern "C" functions throw exceptions Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 23:22 +0000
                  Re: Can extern "C" functions throw exceptions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 17:03 -0700
      Re: Can extern "C" functions throw exceptions HorseyWorsey@the_stables.com - 2021-09-11 15:56 +0000
      Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-11 20:10 +0200
        Re: Can extern "C" functions throw exceptions Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:20 +0000
          Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-12 12:34 +0300
          Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-12 12:24 +0200
            Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-12 12:29 +0200
          Re: Can extern "C" functions throw exceptions Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-09-12 14:44 +0100
            Re: Can extern "C" functions throw exceptions James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:13 -0400
              Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-13 09:30 +0200
              Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:12 -0700
                Re: Can extern "C" functions throw exceptions "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-07 07:09 -0700
                  Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-14 15:21 -0800
                    Re: Can extern "C" functions throw exceptions Richard Damon <Richard@Damon-Family.org> - 2021-12-14 21:17 -0500
                      Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:21 -0800
                    Re: Can extern "C" functions throw exceptions "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-14 19:06 -0800
                      Re: Can extern "C" functions throw exceptions Ian Collins <ian-news@hotmail.com> - 2021-12-16 13:14 +1300
                        Re: Can extern "C" functions throw exceptions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-15 18:05 -0800
                        Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:37 -0800
                          Re: Can extern "C" functions throw exceptions Ian Collins <ian-news@hotmail.com> - 2021-12-17 09:39 +1300
                            Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 19:24 -0800
                      Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:29 -0800
            Re: Can extern "C" functions throw exceptions Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:34 +0000
              Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-13 09:55 +0300
    Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-11 15:12 +0300
    Re: Can extern "C" functions throw exceptions red floyd <no.spam.here@its.invalid> - 2021-09-13 13:21 -0700

Page 1 of 2  [1] 2  Next page →

#81161 — Can extern "C" functions throw exceptions

Is it specified that extern "C" functions never throw exceptions.
If it is I see a problem with this: if I pass a function-pointer
to a C++-function an extern "C" function and this function is
called through its pointer by the extern "C" function it might
throw an exception.

[toc] | [next] | [standalone]

#81163

On 2021-09-11 at 12:35, Bonita Montero wrote:
> Is it specified that extern "C" functions never throw exceptions.

No.

> If it is I see a problem with this: if I pass a function-pointer
> to a C++-function an extern "C" function and this function is
> called through its pointer by the extern "C" function it might
> throw an exception.

Can you really pass an extern "C++" function pointer to an extern "C" 
function?

Also, if the C function is compiled with a C compiler, it probably 
doesn't know how to handle an exception.

[toc] | [prev] | [next] | [standalone]

#81165

On 11 Sep 2021 13:49, Bo Persson wrote:
> On 2021-09-11 at 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
> 
> No.
> 
>> If it is I see a problem with this: if I pass a function-pointer
>> to a C++-function an extern "C" function and this function is
>> called through its pointer by the extern "C" function it might
>> throw an exception.
> 
> Can you really pass an extern "C++" function pointer to an extern "C" 
> function?

Yes, in practice, but not formally.

As I recall from earlier discussions only the/a Solaris compiler 
warns/warned by default.

Happily that warning could be turned off.


> Also, if the C function is compiled with a C compiler, it probably 
> doesn't know how to handle an exception.

Yes.


- Alf

[toc] | [prev] | [next] | [standalone]

#81168

11.09.2021 14:49 Bo Persson kirjutas:
> On 2021-09-11 at 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
> 
> No.
> 
>> If it is I see a problem with this: if I pass a function-pointer
>> to a C++-function an extern "C" function and this function is
>> called through its pointer by the extern "C" function it might
>> throw an exception.
> 
> Can you really pass an extern "C++" function pointer to an extern "C" 
> function?

Sure, an extern "C" function in C++ can have any C++ types as 
parameters. It would be just become impossible to call it from C, but 
you can still can call it from C++ code.

One might want to do this in order to have a non-mangled function name 
to be looked up by dladdr()/GetProcAddress().

[toc] | [prev] | [next] | [standalone]

#81169

Am 11.09.2021 um 13:49 schrieb Bo Persson:
> On 2021-09-11 at 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
> 
> No.
> 
>> If it is I see a problem with this: if I pass a function-pointer
>> to a C++-function an extern "C" function and this function is
>> called through its pointer by the extern "C" function it might
>> throw an exception.
> 
> Can you really pass an extern "C++" function pointer to an extern "C" 
> function?

Of course you can:

#include <iostream>

using namespace std;


#if defined(_MSC_VER)
	#define NOINLINE __declspec(noinline)
#elif defined(__GNUC__) || defined(__clang__)
	#define NOINLINE __attribute((noinline))
#endif

extern "C"
NOINLINE
void f( void (*fn)() )
{
	fn();
}

NOINLINE
void thrower()
{
	throw "hello world";
}

int main()
{
	try
	{
		f( thrower );
	}
	catch( char const *str )
	{
		cout << str << endl;
	}
}

And MSVC, clang and gcc generate unwind-handlers for "void f()",
i.e. f() isn't implicitly noexcept, but I don't know whether this
is mandated by the standard.

[toc] | [prev] | [next] | [standalone]

#81177

On Sat, 11 Sep 2021 13:49:34 +0200
Bo Persson <bo@bo-persson.se> wrote:
>On 2021-09-11 at 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
>
>No.
>
>> If it is I see a problem with this: if I pass a function-pointer
>> to a C++-function an extern "C" function and this function is
>> called through its pointer by the extern "C" function it might
>> throw an exception.
>
>Can you really pass an extern "C++" function pointer to an extern "C" 
>function?
>
>Also, if the C function is compiled with a C compiler, it probably 
>doesn't know how to handle an exception.

Would it need to? I guess it depends ultimately on how exceptions are actually
converted into assembler by the given compiler and whether during compile time
its smart enough to set the exception jumps to skip C functions on the stack
entirely.

[toc] | [prev] | [next] | [standalone]

#81164

On 11 Sep 2021 12:35, Bonita Montero wrote:
> Is it specified that extern "C" functions never throw exceptions.

No, I don't think so, but that's a common and reasonable assumption.


> If it is I see a problem with this: if I pass a function-pointer
> to a C++-function an extern "C" function and this function is
> called through its pointer by the extern "C" function it might
> throw an exception.

Yes, that can for example happen in Windows desktop programming in a 
WM_PAINT handler.

If one lets the exception just propagate normally up to the C++ code 
above, then every C function it logically passes through (in reality it 
just jumps all the way back up directly) may leak some resources.

One way to deal with it is to use `std::current_exception` to obtain an 
exception pointer, store that in static storage somewhere, return 
normally up through the C call chain, and re-throw in the higher level 
C++ code that passed the C callback to be called.

I must have written such exception propagation support at least five 
times. One gets wary of it. Why on Earth does the standard not supply 
the mechanism, only the building blocks to make it?

And ditto for retrieving the exception messages of nested exceptions: 
why on Earth should every individual programmer have to re-invent that 
wheel in every app?


- Alf

[toc] | [prev] | [next] | [standalone]

#81170

Am 11.09.2021 um 13:55 schrieb Alf P. Steinbach:
> On 11 Sep 2021 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
> 
> No, I don't think so, but that's a common and reasonable assumption.
> 
> 
>> If it is I see a problem with this: if I pass a function-pointer
>> to a C++-function an extern "C" function and this function is
>> called through its pointer by the extern "C" function it might
>> throw an exception.
> 
> Yes, that can for example happen in Windows desktop programming in a 
> WM_PAINT handler.

I'm pretty sure the WndProc handling WM_PAINT can't throw an exception
because the Windows-APIs calling it don't have any unwind-handlers, i.e.
linked unrolling with 32 bit code or table-driven unrolled handlers for
32 bit code.

[toc] | [prev] | [next] | [standalone]

#81171

Am 11.09.2021 um 15:34 schrieb Bonita Montero:
> Am 11.09.2021 um 13:55 schrieb Alf P. Steinbach:
>> On 11 Sep 2021 12:35, Bonita Montero wrote:
>>> Is it specified that extern "C" functions never throw exceptions.
>>
>> No, I don't think so, but that's a common and reasonable assumption.
>>
>>
>>> If it is I see a problem with this: if I pass a function-pointer
>>> to a C++-function an extern "C" function and this function is
>>> called through its pointer by the extern "C" function it might
>>> throw an exception.
>>
>> Yes, that can for example happen in Windows desktop programming in a 
>> WM_PAINT handler.
> 
> I'm pretty sure the WndProc handling WM_PAINT can't throw an exception
> because the Windows-APIs calling it don't have any unwind-handlers, i.e.
> linked unrolling with 32 bit code or table-driven unrolled handlers for
> 32 bit code.
   ^^ 64

[toc] | [prev] | [next] | [standalone]

#81174

On 11 Sep 2021 15:34, Bonita Montero wrote:
> Am 11.09.2021 um 13:55 schrieb Alf P. Steinbach:
>> On 11 Sep 2021 12:35, Bonita Montero wrote:
>>> Is it specified that extern "C" functions never throw exceptions.
>>
>> No, I don't think so, but that's a common and reasonable assumption.
>>
>>
>>> If it is I see a problem with this: if I pass a function-pointer
>>> to a C++-function an extern "C" function and this function is
>>> called through its pointer by the extern "C" function it might
>>> throw an exception.
>>
>> Yes, that can for example happen in Windows desktop programming in a 
>> WM_PAINT handler.
> 
> I'm pretty sure the WndProc handling WM_PAINT can't throw an exception
> because the Windows-APIs calling it don't have any unwind-handlers, i.e.
> linked unrolling with 32 bit code or table-driven unrolled handlers for
> 32 bit code.

You're right that the Windows code calling it lacks unwind-handlers for 
C++ exceptions.

The part you snipped discussed one way to deal with that in C++11 and 
later, because it's the general problem with exceptions in C callbacks 
provided by C++ code.

Note that the WM_PAINT handler is generally C++ app code, and it can 
throw exceptions by design and/or inadvertently. I prefer to deal with 
that. I do know from discussions with some Microsoft programmers (both 
when the Microsoft Usenet servers were still going, via mailing list 
when I was an MSVP in Visual C++ in 2012/13, and later at Reddit and 
elsewhere) that they don't quite understand the need to deal with 
exceptions or how, and that they generally don't understand the utility 
of exceptions in such code, in particular for DirectX where the most 
vocal of them erroneously believe that exceptions can't be used, and 
that they absolutely have to be right about that because everyone they 
know believe the same... But then, these are they guys writing `void 
main` and so on. And these are the guys creating a Windows calculator 
that by default evaluates 2+3*4 as (2+3)*4. And so on. And on. :-o

- Alf

[toc] | [prev] | [next] | [standalone]

#81884

On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote:

> And these are the guys creating a Windows calculator 
> that by default evaluates 2+3*4 as (2+3)*4. 

In Standard mode, but not in Scientific or Programmer mode :-)

[toc] | [prev] | [next] | [standalone]

#81885

On 2021-10-06, daniel...@gmail.com <danielaparker@gmail.com> wrote:
> On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote:
>
>> And these are the guys creating a Windows calculator 
>> that by default evaluates 2+3*4 as (2+3)*4. 
>
> In Standard mode, but not in Scientific or Programmer mode :-)
--main = print $ calculate "3 * 2 + 5 / 2"
            
calculate :: String -> String
calculate str = case (eval operatorRegister . words) str of
            Just r -> printf "%.2f" (fromRational r::Double)
            Nothing -> "Nothing"
            
eval :: Register -> [String] -> Maybe Rational
eval [] _ = Nothing -- No operator found.
eval _ [] = Nothing -- If a operator don't have anything to operate on.
eval _ [number] = let a :: Maybe Double = readMaybe number
                  in case a of
                     Just a -> Just (toRational a)
                     Nothing -> Nothing
eval ((operator, function):rest) unparsed =
    case span (/=operator) unparsed of
        (_, []) -> eval rest unparsed
        (beforeOperator, afterOperator) -> 
            function
                <$> (eval operatorRegister beforeOperator)
                <*> (eval operatorRegister $ drop 1 afterOperator)


-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81887

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-06, daniel...@gmail.com <danielaparker@gmail.com> wrote:
>> On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote:
>>
>>> And these are the guys creating a Windows calculator 
>>> that by default evaluates 2+3*4 as (2+3)*4. 
>>
>> In Standard mode, but not in Scientific or Programmer mode :-)
> --main = print $ calculate "3 * 2 + 5 / 2"
>             
> calculate :: String -> String
> calculate str = case (eval operatorRegister . words) str of
>             Just r -> printf "%.2f" (fromRational r::Double)
>             Nothing -> "Nothing"
>             
> eval :: Register -> [String] -> Maybe Rational
> eval [] _ = Nothing -- No operator found.
> eval _ [] = Nothing -- If a operator don't have anything to operate on.
> eval _ [number] = let a :: Maybe Double = readMaybe number
>                   in case a of
>                      Just a -> Just (toRational a)
>                      Nothing -> Nothing
> eval ((operator, function):rest) unparsed =
>     case span (/=operator) unparsed of
>         (_, []) -> eval rest unparsed
>         (beforeOperator, afterOperator) -> 
>             function
>                 <$> (eval operatorRegister beforeOperator)
>                 <*> (eval operatorRegister $ drop 1 afterOperator)

I don't know what language that is, and you haven't bothered to tell us.
(No, I'm not asking, just saying that whatever point your post might
have is defeated by not knowing what language you're using.)

Again, you've posted something that isn't relevant either to the subject
of this newsgroup (the C++ language) or to the thread (which is about
extern "C" functions throwing exceptions, with a passing reference to
the Windows calculator program).

This kind of thing is a problem.  I can solve it for myself by
configuring my newsreader to stop showing me your posts.  You can solve
it for everyone by not making off-topic posts.  (The fact that you post
obscure things without any explanation is just icing on the unpleasant
cake.)  Please don't just post whatever you think is interesting.
Consider whether it's appropriate.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#81888

On 2021-10-06, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-06, daniel...@gmail.com <danielaparker@gmail.com> wrote:
>>> On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote:
>>>
>>>> And these are the guys creating a Windows calculator 
>>>> that by default evaluates 2+3*4 as (2+3)*4. 
>>>
>>> In Standard mode, but not in Scientific or Programmer mode :-)
>> --main = print $ calculate "3 * 2 + 5 / 2"
>>             
>> calculate :: String -> String
>> calculate str = case (eval operatorRegister . words) str of
>>             Just r -> printf "%.2f" (fromRational r::Double)
>>             Nothing -> "Nothing"
>>             
>> eval :: Register -> [String] -> Maybe Rational
>> eval [] _ = Nothing -- No operator found.
>> eval _ [] = Nothing -- If a operator don't have anything to operate on.
>> eval _ [number] = let a :: Maybe Double = readMaybe number
>>                   in case a of
>>                      Just a -> Just (toRational a)
>>                      Nothing -> Nothing
>> eval ((operator, function):rest) unparsed =
>>     case span (/=operator) unparsed of
>>         (_, []) -> eval rest unparsed
>>         (beforeOperator, afterOperator) -> 
>>             function
>>                 <$> (eval operatorRegister beforeOperator)
>>                 <*> (eval operatorRegister $ drop 1 afterOperator)
>
> I don't know what language that is, and you haven't bothered to tell us.
> (No, I'm not asking, just saying that whatever point your post might
> have is defeated by not knowing what language you're using.)
>

Petty, one of the favorite Hacker languages :P
(Haskell) , besides /forth and ASSE/mbler :P

> Again, you've posted something that isn't relevant either to the subject
> of this newsgroup (the C++ language) or to the thread (which is about
> extern "C" functions throwing exceptions, with a passing reference to
> the Windows calculator program).
>

Who cares, this is not *mderated* group, you just embarrased yourself
not recognizing simple calculator in Haskell :P

> Consider whether it's appropriate.
>
It is talk was about calculator :p

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81889

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-06, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Again, you've posted something that isn't relevant either to the subject
>> of this newsgroup (the C++ language) or to the thread (which is about
>> extern "C" functions throwing exceptions, with a passing reference to
>> the Windows calculator program).
>
> Who cares, this is not *mderated* group, you just embarrased yourself
> not recognizing simple calculator in Haskell :P

I care, and most readers here do as well.

>> Consider whether it's appropriate.
>>
> It is talk was about calculator :p

*PLONK*

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#81178

On Sat, 11 Sep 2021 13:55:43 +0200
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:
>And ditto for retrieving the exception messages of nested exceptions: 
>why on Earth should every individual programmer have to re-invent that 
>wheel in every app?

If so many programmers didn't use exceptions as fancy gotos they probably
wouldn't have to much if ever. An exception should be for an exceptional
situation, the clue is in the name, not simply a convenient way to avoid doing
manual returns up the call stack.

[toc] | [prev] | [next] | [standalone]

#81182

On 11/09/2021 13:55, Alf P. Steinbach wrote:
> On 11 Sep 2021 12:35, Bonita Montero wrote:
>> Is it specified that extern "C" functions never throw exceptions.
> 
> No, I don't think so, but that's a common and reasonable assumption.
> 

extern "C" marks the function as having C naming conventions and C
calling conventions (which may, in theory, differ from C++ conventions -
though I have never heard of that in practice).  But there is nothing to
stop a C++ function being marked extern "C" - I have done that in my own
code, in connection with overriding weak alias functions defined in C or
when I needed a non-mangled name for the function.

If we are talking about external C functions - functions compiled in a C
unit by a C compiler - then it is reasonable to assume that the function
itself will not throw any exceptions.  You'd need C compiler extensions
to support that.  However, the C function could call C++ functions that
in turn throw exceptions - the external C function would then be passing
on exceptions, even though it did not throw any itself.

[toc] | [prev] | [next] | [standalone]

#81194

David Brown <david.brown@hesbynett.no> wrote:
> extern "C" marks the function as having C naming conventions and C
> calling conventions

Indeed, extern "C" doesn't mean that the code being called using
those functions has actually been compiled as C. It merely changes
the naming of the functions in the object files to be compatible
with how functions are named in C.

But that makes me wonder: If an extern "C" declared function has
C++ types as parameters (or return value type), how are those
encoded in the name? Or are they at all? Can you overload extern "C"
functions?

[toc] | [prev] | [next] | [standalone]

#81199

12.09.2021 12:20 Juha Nieminen kirjutas:
> David Brown <david.brown@hesbynett.no> wrote:
>> extern "C" marks the function as having C naming conventions and C
>> calling conventions
> 
> Indeed, extern "C" doesn't mean that the code being called using
> those functions has actually been compiled as C. It merely changes
> the naming of the functions in the object files to be compatible
> with how functions are named in C.
> 
> But that makes me wonder: If an extern "C" declared function has
> C++ types as parameters (or return value type), how are those
> encoded in the name? Or are they at all? 

They aren't.

 > Can you overload extern "C"
 > functions?

No.

[toc] | [prev] | [next] | [standalone]

#81206

On 12/09/2021 11:20, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> extern "C" marks the function as having C naming conventions and C
>> calling conventions
> 
> Indeed, extern "C" doesn't mean that the code being called using
> those functions has actually been compiled as C. It merely changes
> the naming of the functions in the object files to be compatible
> with how functions are named in C.
> 
> But that makes me wonder: If an extern "C" declared function has
> C++ types as parameters (or return value type), how are those
> encoded in the name? 

They are not.

> Or are they at all? Can you overload extern "C"
> functions?
> 

No.

Although in theory a compiler can support different ABI's or calling
conventions for C and C++ functions, in practice making a function
extern "C" simply disables all name mangling for the function.  That in
turn means you can't overload it, or have it in a namespace.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web