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.
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?
extern "C" marks the function as having C naming conventions and C
calling conventions
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.
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?
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?
On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)...
Juha Nieminen <nospam@thanks.invalid> wrote:
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.
For functions, it does more than affecting naming. The language linkage
of a function determines two things: the function's name (name mangling)
and the function's type (calling convention).
gcc allows you to pass a function pointer
with C++ language linkage to a C function expecting a C function
pointer, but strictly speaking it is undefined behaviour.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
gcc allows you to pass a function pointer
with C++ language linkage to a C function expecting a C function
pointer, but strictly speaking it is undefined behaviour.
Does that mean that if you are using a C library and you give it a
function pointer (eg. a callback function), you ought to make that
function extern "C"?
How about std::qsort()? Does its comparator function pointer need to be declared extern "C"? (Or does the standard require std::qsort() to be
usable with C++ function pointers directly?)
On 9/12/21 9:44 AM, Chris Vine wrote:
On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)...
Juha Nieminen <nospam@thanks.invalid> wrote:
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.
For functions, it does more than affecting naming. The language linkage
of a function determines two things: the function's name (name mangling)
and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects are separable
by using a typedef for a function's type. The language linkage of the
typedef determines the calling convention, while the language linkage of
the function itself determines the name mangling.
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.
On 9/12/21 9:44 AM, Chris Vine wrote:
On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
...
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.
For functions, it does more than affecting naming. The language
linkage of a function determines two things: the function's name
(name mangling) and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects are
separable by using a typedef for a function's type. The language
linkage of the typedef determines the calling convention, while the
language linkage of the function itself determines the name
mangling.
And these are the guys creating a Windows calculator
that by default evaluates 2+3*4 as (2+3)*4.
On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote:--main = print $ calculate "3 * 2 + 5 / 2"
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 :-)
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:--main = print $ calculate "3 * 2 + 5 / 2"
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 :-)
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)
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
Consider whether it's appropriate.It is talk was about calculator :p
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:--main = print $ calculate "3 * 2 + 5 / 2"
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 :-)
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).
Consider whether it's appropriate.
James Kuyper <james...@alumni.caltech.edu> writes:...
On 9/12/21 9:44 AM, Chris Vine wrote:
For functions, it does more than affecting naming. The language
linkage of a function determines two things: the function's name
(name mangling) and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects areCan you illustrate how that would be done? Since the language
separable by using a typedef for a function's type. The language
linkage of the typedef determines the calling convention, while the language linkage of the function itself determines the name
mangling.
linkage of a function is part of its type, it sounds like trying
to do such a thing would inevitably lead to undefined behavior.
On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
James Kuyper <james...@alumni.caltech.edu> writes:
On 9/12/21 9:44 AM, Chris Vine wrote:
...
For functions, it does more than affecting naming. The language
linkage of a function determines two things: the function's name
(name mangling) and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects are
separable by using a typedef for a function's type. The language
linkage of the typedef determines the calling convention, while the
language linkage of the function itself determines the name
mangling.
Can you illustrate how that would be done? Since the language
linkage of a function is part of its type, it sounds like trying
to do such a thing would inevitably lead to undefined behavior.
The language linkage of a function's type is indeed part of that type. The language linkage of a function's name is not. The standard's description of language linkage in 9.11p1 starts with the sentence "All function types, function names with external linkage, and variable names with external linkage have a language linkage.", clearly making the point that the
language linkage of a function's type is a distinct thing from the language linkage of a function's name. The standard could have inextricably linked them together - but it does not. In fact, 9.11p5 includes an example demonstrating how they can be separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:...
The language linkage of a function's type is indeed part of that type. The language linkage of a function's name is not. The standard's description of language linkage in 9.11p1 starts with the sentence "All function types, function names with external linkage, and variable names with external linkage have a language linkage.", clearly making the point that the language linkage of a function's type is a distinct thing from the language linkage of a function's name. The standard could have inextricably linked them together - but it does not. In fact, 9.11p5 includes an example demonstrating how they can be separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/ is-extern-c-a-part-of-the-type-of-a-function
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
James Kuyper <james...@alumni.caltech.edu> writes:
On 9/12/21 9:44 AM, Chris Vine wrote:
...
For functions, it does more than affecting naming. The language
linkage of a function determines two things: the function's name
(name mangling) and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects are
separable by using a typedef for a function's type. The language
linkage of the typedef determines the calling convention, while the
language linkage of the function itself determines the name
mangling.
Can you illustrate how that would be done? Since the language
linkage of a function is part of its type, it sounds like trying
to do such a thing would inevitably lead to undefined behavior.
The language linkage of a function's type is indeed part of that type. The >> language linkage of a function's name is not. The standard's description of >> language linkage in 9.11p1 starts with the sentence "All function types,
function names with external linkage, and variable names with external
linkage have a language linkage.", clearly making the point that the
language linkage of a function's type is a distinct thing from the language >> linkage of a function's name. The standard could have inextricably linked >> them together - but it does not. In fact, 9.11p5 includes an example
demonstrating how they can be separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:...
The language linkage of a function's type is indeed part of that type. The >>> language linkage of a function's name is not. The standard's description of >>> language linkage in 9.11p1 starts with the sentence "All function types, >>> function names with external linkage, and variable names with external
linkage have a language linkage.", clearly making the point that the
language linkage of a function's type is a distinct thing from the language >>> linkage of a function's name. The standard could have inextricably linked >>> them together - but it does not. In fact, 9.11p5 includes an example
demonstrating how they can be separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
If you can figure out words to express your remaining questions, I'd be curious
to find out what they are.
It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
The standard is quite clear: "Two function types with different language linkages are distinct types even if they are otherwise identical." (9.11p1). I'm
annoyed, but unfortunately not surprised, to find that this has been ignored. I've never had any need to write code where that issue would matter, which
is why I've never noticed.
On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:[...]
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
I have only used one compiler, Sun CC, that bothered to enforce the
rule. At the time, the main problem this caused me was it prevented
static member functions being passed to pthread_create, I had to use
extern "C" qualified friend function on Solaris.
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
...
The language linkage of a function's type is indeed part of that
type. The language linkage of a function's name is not. The
standard's description of language linkage in 9.11p1 starts with
the sentence "All function types, function names with external
linkage, and variable names with external linkage have a
language linkage.", clearly making the point that the language
linkage of a function's type is a distinct thing from the
language linkage of a function's name. The standard could have
inextricably linked them together - but it does not. In fact,
9.11p5 includes an example demonstrating how they can be
separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
If you can figure out words to express your remaining questions,
I'd be curious to find out what they are.
It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
The standard is quite clear: "Two function types with different
language linkages are distinct types even if they are otherwise
identical." (9.11p1). [...]
On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
...
The language linkage of a function's type is indeed part of
that type. The language linkage of a function's name is not.
The standard's description of language linkage in 9.11p1 starts
with the sentence "All function types, function names with
external linkage, and variable names with external linkage have
a language linkage.", clearly making the point that the
language linkage of a function's type is a distinct thing from
the language linkage of a function's name. The standard could
have inextricably linked them together - but it does not. In
fact, 9.11p5 includes an example demonstrating how they can be
separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
If you can figure out words to express your remaining questions,
I'd be curious to find out what they are.
>> It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
The standard is quite clear: "Two function types with different
language linkages are distinct types even if they are otherwise
identical." (9.11p1). I'm annoyed, but unfortunately not
surprised, to find that this has been ignored. I've never had
any need to write code where that issue would matter, which is
why I've never noticed.
I have only used one compiler, Sun CC, that bothered to enforce
the rule. At the time, the main problem this caused me was it
prevented static member functions being passed to pthread_create,
I had to use extern "C" qualified friend function on Solaris.
On 12/14/21 6:21 PM, Tim Rentsch wrote:
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
James Kuyper <james...@alumni.caltech.edu> writes:
On 9/12/21 9:44 AM, Chris Vine wrote:
...
For functions, it does more than affecting naming. The language
linkage of a function determines two things: the function's name
(name mangling) and the function's type (calling convention).
Furthermore, and not widely appreciated, those two aspects are
separable by using a typedef for a function's type. The language
linkage of the typedef determines the calling convention, while
the language linkage of the function itself determines the name
mangling.
Can you illustrate how that would be done? Since the language
linkage of a function is part of its type, it sounds like trying
to do such a thing would inevitably lead to undefined behavior.
The language linkage of a function's type is indeed part of that
type. The language linkage of a function's name is not. The
standard's description of language linkage in 9.11p1 starts with
the sentence "All function types, function names with external
linkage, and variable names with external linkage have a language
linkage.", clearly making the point that the language linkage of a
function's type is a distinct thing from the language linkage of a
function's name. The standard could have inextricably linked them
together - but it does not. In fact, 9.11p5 includes an example
demonstrating how they can be separated:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function?s type has C language linkage
[...]
Thank you for this citation. It doesn't answer all my questions
but it certainly does provide an illuminating example.
It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
Maybe a better way of saying that is most platform ABIs don't allow
for a difference, because it would break too much existing code.
Ian Collins <ian-news@hotmail.com> writes:
On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
The standard is quite clear: "Two function types with different
language linkages are distinct types even if they are otherwise
identical." (9.11p1). I'm annoyed, but unfortunately not
surprised, to find that this has been ignored. I've never had
any need to write code where that issue would matter, which is
why I've never noticed.
I have only used one compiler, Sun CC, that bothered to enforce
the rule. At the time, the main problem this caused me was it
prevented static member functions being passed to pthread_create,
I had to use extern "C" qualified friend function on Solaris.
Did you try a pattern like this:
extern "C" typedef void Whatsit( double * );
class Foo {
public:
static Whatsit fred;
};
void
Foo::fred( double *things ){
for( int i = 0; i < 10; i++ ) things[i] += i;
}
This code is accepted by g++ back to -std=c++98. Of course,
since we know the gnu tools are compromised that doesn't tell us
very much...
On 17/12/2021 01:37, Tim Rentsch wrote:
Ian Collins <ian-news@hotmail.com> writes:
On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
between a type with a C language linkage and a C++ language
linkage. Apparently most compilers ignore the distinction
because following the rules would break too much code. Here
is a link to stackoverflow with more information:
https://stackoverflow.com/questions/26647259/
is-extern-c-a-part-of-the-type-of-a-function
The standard is quite clear: "Two function types with different
language linkages are distinct types even if they are otherwise
identical." (9.11p1). I'm annoyed, but unfortunately not
surprised, to find that this has been ignored. I've never had
any need to write code where that issue would matter, which is
why I've never noticed.
I have only used one compiler, Sun CC, that bothered to enforce
the rule. At the time, the main problem this caused me was it
prevented static member functions being passed to pthread_create,
I had to use extern "C" qualified friend function on Solaris.
Did you try a pattern like this:
extern "C" typedef void Whatsit( double * );
class Foo {
public:
static Whatsit fred;
};
void
Foo::fred( double *things ){
for( int i = 0; i < 10; i++ ) things[i] += i;
}
This code is accepted by g++ back to -std=c++98. Of course,
since we know the gnu tools are compromised that doesn't tell us
very much...
No, I just used friend unctions, your suggestion would have been
interesting to try, but I no longer have those tools installed.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 185 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 11:01:16 |
| Calls: | 3,678 |
| Calls today: | 4 |
| Files: | 11,151 |
| Messages: | 3,447,871 |