#ifdef __cplusplus

[mattia]

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

Thanks

--
__mattia__

[Richard Heathfield]

mattia said:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.
Best avoided.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Walter Roberson]

In article <47***********************@reader4.news.tin.it>,
mattia <ge****@gmail.comwrote:

>I've see in some code:

>#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

This has to do with C++. A C compiler will not defne __cplusplus
and so a C compiler will compile those lines to nothingness.

This form detects that whether the code is being compiled with a C++
compiler, and if it is, wraps extern "C" { } around the block of code.
The meaning of extern "C" { } is specific to C++, and in C++ means
that the enclosed block of code is to have its functions compiled
with C calling sequences rather than C++ calling sequences. The
single most important difference between C calling sequences and C++
calling sequences is that C++ calling sequences (usually) have
a hidden parameter named "this" that refers to the object being
operated upon; using this syntax in C++ tells C++ to not put in
that hidden parameter, thus leaving the functions defined suitable for
calling from C (or, alternately, -declaring- functions as being
external functions that need C-style parameters to call.)
--
"When we all think alike no one is thinking very much."
-- Walter Lippmann

[Kaz Kylheku]

On Apr 9, 9:26*am, mattia <[e-mail]:

I've see in some code:

#ifdef __cplusplus
*extern "C"
*{
#endif

what does it mean?

It means that the tokens extern "C" { are part of the
translation unit if the __cplusplus preprocessor symbol is defined.

Somewhere farther down, there should be a matching

#ifdef __cplusplus
}
#endif

to close the brace.

[Antoninus Twink]

On 9 Apr 2008 at 16:26, mattia wrote:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

C++ supports certain powerful but complex features that mean that
different functions and variables can have different names:
specifically, in C++ function names can be overloaded (two functions can
have the same name, but different argument signatures), and also C++
supports "namespaces", which granulate visibility in C's single global
external namespace.

To get around these problems, C++ compilers commonly "mangle" function
names: that is, the function name that appears in the global namespace
will be a string obtained in some way or other from the actual name of
the function as it appears in the code, the type and number of its
arguments, and any namespace qualifications needed to specify it.

This means that if a C++ program tries to use functions from a C
library, then there will be problems: when the C++ linker sees a
function called foobar, it will actually look in the symbol table for
something like foorbar__Fii.

To get around this, there's a way for the programmer to tell his
C++ linker that some of the functions have "C linkage", and so it
shouldn't try to mangle their names. This is achived by surrounding the
code with
extern "C" {
....
}

Sometimes, people write functions in C and then want to create a single
header that will let people use their functions either in C or C++.

To accomplish this, they make use of the fact that the macro __cplusplus
will be defined by the compiler if and only if it's compiling the
program as C++, and include the extern "C" lines conditional on the
presence of this macro. Therefore, if the file is being compiled as C
then this little bit of C++ will vanish during preprocessing, and won't
choke the C compiler.

[Philip Potter]

mattia wrote:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

Thanks

Others have stated what it means; I'd just add that I've usually seen
this idiom used in system header files (such as stdio.h) so that the
same header can be used for both C and C++ compilers. C compilers (DS9K
excluded) don't define __cplusplus and don't see the extern "C" bit,
while C++ compilers do define it and so know that all the stdio.h
functions declared are C-style functions and linked in a C-style way.

I wouldn't recommend this practice in your own code.

extern "C" has no defined meaning in C. You'd probably get better
answers in comp.lang.c++.

Philip

[Richard]

Antoninus Twink <no****@nospam.invalidwrites:

On 9 Apr 2008 at 16:26, mattia wrote:

>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

C++ supports certain powerful but complex features that mean that
different functions and variables can have different names:
specifically, in C++ function names can be overloaded (two functions can
have the same name, but different argument signatures), and also C++
supports "namespaces", which granulate visibility in C's single global
external namespace.

To get around these problems, C++ compilers commonly "mangle" function
names: that is, the function name that appears in the global namespace
will be a string obtained in some way or other from the actual name of
the function as it appears in the code, the type and number of its
arguments, and any namespace qualifications needed to specify it.

This means that if a C++ program tries to use functions from a C
library, then there will be problems: when the C++ linker sees a
function called foobar, it will actually look in the symbol table for
something like foorbar__Fii.

To get around this, there's a way for the programmer to tell his
C++ linker that some of the functions have "C linkage", and so it
shouldn't try to mangle their names. This is achived by surrounding the
code with
extern "C" {
...
}

Sometimes, people write functions in C and then want to create a single
header that will let people use their functions either in C or C++.

To accomplish this, they make use of the fact that the macro __cplusplus
will be defined by the compiler if and only if it's compiling the
program as C++, and include the extern "C" lines conditional on the
presence of this macro. Therefore, if the file is being compiled as C
then this little bit of C++ will vanish during preprocessing, and won't
choke the C compiler.

Very well explained. I'm amazed no one has scolded you and told the OP
that the "experts" are down the corridoor second on the left ....

[Antoninus Twink]

On 9 Apr 2008 at 17:48, Richard wrote:

Very well explained. I'm amazed no one has scolded you and told the OP
that the "experts" are down the corridoor second on the left ....

Thanks.

Luckily they've all kill-filed me, so I can safely post useful
information without generating a dozen flames in response.

[Ben Bacarisse]

Philip Potter <pg*@doc.ic.ac.ukwrites:

Walter Roberson wrote:

>In article <47***********************@reader4.news.tin.it>,
mattia <ge****@gmail.comwrote:

>>I've see in some code:

>>#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

This has to do with C++. A C compiler will not defne __cplusplus
and so a C compiler will compile those lines to nothingness.

My DS9K defines __cplusplus.

(By which I mean, there's nothing in the C Standard preventing a
conforming implementation defining __cplusplus, though it would be a
Dumb Thing for a C implementation to do, and I'd be happy relying on my
implementation not to define it.)

In section 6.10.8 (Predefined macro names) paragraph 5 read:

The implementation shall not predefine the macro __cplusplus, nor
shall it define it in any standard header.

--
Ben.

[Philip Potter]

Ben Bacarisse wrote:

Philip Potter <pg*@doc.ic.ac.ukwrites:

>My DS9K defines __cplusplus.

(By which I mean, there's nothing in the C Standard preventing a
conforming implementation defining __cplusplus, though it would be a
Dumb Thing for a C implementation to do, and I'd be happy relying on my
implementation not to define it.)

In section 6.10.8 (Predefined macro names) paragraph 5 read:

The implementation shall not predefine the macro __cplusplus, nor
shall it define it in any standard header.

Well I never! I stand completely and utterly corrected. Is that in C89 too?

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 9 Apr 2008 at 17:48, Richard wrote:

>Very well explained. I'm amazed no one has scolded you and told the OP
that the "experts" are down the corridoor second on the left ....

Thanks.

Luckily they've all kill-filed me, so I can safely post useful
information without generating a dozen flames in response.

It sounds like you have actually solved the problem of CLC.

Congratulations.

Essentially, there will be two CLCs - the one populated and run by the
regs (which, as we know, is 65% endless topicality BS, 30% beginner
questions and answers[*], and 5% [boring] lawyering) - and the other
one (unseen, as you say, by the regs) populated by the rest of us.
[*] By the way, tell me again, how _do_ you prototype main()?

[Flash Gordon]

Philip Potter wrote, On 09/04/08 18:39:

Walter Roberson wrote:

<snip>

>This has to do with C++. A C compiler will not defne __cplusplus
and so a C compiler will compile those lines to nothingness.

My DS9K defines __cplusplus.

In which case you should upgrade to the C99 compiler for the DS9K.

(By which I mean, there's nothing in the C Standard preventing a
conforming implementation defining __cplusplus, though it would be a
Dumb Thing for a C implementation to do, and I'd be happy relying on my
implementation not to define it.)

<snip>

C99 banned implementations from defining __cplusplus
--
Flash Gordon

[Flash Gordon]

Richard Heathfield wrote, On 09/04/08 17:41:

mattia said:

>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

No it does not. It is generally used in the header when the library is
written in C but might be called from C++.

Best avoided.

No, best used when it is appropriate.

For more discussion about this the correct place would be comp.lang.c++
--
Flash Gordon

[Richard]

Philip Potter <pg*@doc.ic.ac.ukwrites:

mattia wrote:

>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

Thanks

Others have stated what it means; I'd just add that I've usually seen
this idiom used in system header files (such as stdio.h) so that the
same header can be used for both C and C++ compilers. C compilers (DS9K
excluded) don't define __cplusplus and don't see the extern "C" bit,
while C++ compilers do define it and so know that all the stdio.h
functions declared are C-style functions and linked in a C-style way.

I wouldn't recommend this practice in your own code.

extern "C" has no defined meaning in C. You'd probably get better
answers in comp.lang.c++.

Philip

The answer has been given exactly as is more than once. Traipsing over
there is slightly overkill IMO.

[Richard]

Philip Potter <pg*@doc.ic.ac.ukwrites:

Walter Roberson wrote:

>In article <47***********************@reader4.news.tin.it>,
mattia <ge****@gmail.comwrote:

>>I've see in some code:

>>#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

This has to do with C++. A C compiler will not defne __cplusplus
and so a C compiler will compile those lines to nothingness.

My DS9K defines __cplusplus.

(By which I mean, there's nothing in the C Standard preventing a
conforming implementation defining __cplusplus, though it would be a
Dumb Thing for a C implementation to do, and I'd be happy relying on my
implementation not to define it.)

Nonsense. That would make a mockery of the whole thing.

[Philip Potter]

Richard wrote:

Philip Potter <pg*@doc.ic.ac.ukwrites:

>mattia wrote:

>>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

Thanks

Others have stated what it means; I'd just add that I've usually seen
this idiom used in system header files (such as stdio.h) so that the
same header can be used for both C and C++ compilers. C compilers (DS9K
excluded) don't define __cplusplus and don't see the extern "C" bit,
while C++ compilers do define it and so know that all the stdio.h
functions declared are C-style functions and linked in a C-style way.

I wouldn't recommend this practice in your own code.

extern "C" has no defined meaning in C. You'd probably get better
answers in comp.lang.c++.

Philip

The answer has been given exactly as is more than once. Traipsing over
there is slightly overkill IMO.

It's up to the OP. __cplusplus doesn't have much meaning in C, and
extern "C" even less, so if you want to be sure of your answers, you're
better asking a C++ expert.

Phil

[Richard]

Philip Potter <pg*@doc.ic.ac.ukwrites:

Richard wrote:

>Philip Potter <pg*@doc.ic.ac.ukwrites:

>>mattia wrote:
I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

Thanks
Others have stated what it means; I'd just add that I've usually seen
this idiom used in system header files (such as stdio.h) so that the
same header can be used for both C and C++ compilers. C compilers (DS9K
excluded) don't define __cplusplus and don't see the extern "C" bit,
while C++ compilers do define it and so know that all the stdio.h
functions declared are C-style functions and linked in a C-style way.

I wouldn't recommend this practice in your own code.

extern "C" has no defined meaning in C. You'd probably get better
answers in comp.lang.c++.

Philip

The answer has been given exactly as is more than once. Traipsing over
there is slightly overkill IMO.

It's up to the OP. __cplusplus doesn't have much meaning in C, and
extern "C" even less, so if you want to be sure of your answers, you're
better asking a C++ expert.

Phil

As I said - the answer was already posted many times. There are many
here who know both - and it is a "both" question since many C
programmers mix and match.

[Ian Collins]

Richard Heathfield wrote:

mattia said:

>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

Utter nonsense. So are you saying the authours of all my system headers
didn't know which language they're writing in?

--
Ian Collins.

[Keith Thompson]

Philip Potter <pg*@doc.ic.ac.ukwrites:

Ben Bacarisse wrote:

>Philip Potter <pg*@doc.ic.ac.ukwrites:

>>My DS9K defines __cplusplus.

(By which I mean, there's nothing in the C Standard preventing a
conforming implementation defining __cplusplus, though it would be a
Dumb Thing for a C implementation to do, and I'd be happy relying on my
implementation not to define it.)

In section 6.10.8 (Predefined macro names) paragraph 5 read:

The implementation shall not predefine the macro __cplusplus, nor
shall it define it in any standard header.

Well I never! I stand completely and utterly corrected. Is that in C89 too?

I don't think so.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[mattia]

On Wed, 09 Apr 2008 21:34:06 +0200, Richard wrote:

Philip Potter <pg*@doc.ic.ac.ukwrites:

>Richard wrote:

>>Philip Potter <pg*@doc.ic.ac.ukwrites:

mattia wrote:
I've see in some code:
>
#ifdef __cplusplus
extern "C"
{
#endif
>
what does it mean?
>
Thanks
Others have stated what it means; I'd just add that I've usually seen
this idiom used in system header files (such as stdio.h) so that the
same header can be used for both C and C++ compilers. C compilers
(DS9K excluded) don't define __cplusplus and don't see the extern "C"
bit, while C++ compilers do define it and so know that all the
stdio.h functions declared are C-style functions and linked in a
C-style way.

I wouldn't recommend this practice in your own code.

extern "C" has no defined meaning in C. You'd probably get better
answers in comp.lang.c++.

Philip

The answer has been given exactly as is more than once. Traipsing over
there is slightly overkill IMO.

It's up to the OP. __cplusplus doesn't have much meaning in C, and
extern "C" even less, so if you want to be sure of your answers, you're
better asking a C++ expert.

Phil

As I said - the answer was already posted many times. There are many
here who know both - and it is a "both" question since many C
programmers mix and match.

I think that I'll note use __cplusplus unless I'll have to link my
headers with cpp code. That will be my rule. Thanks all for the reply.
--
__mattia__

[Keith Thompson]

Richard <de***@gmail.comwrites:

Antoninus Twink <no****@nospam.invalidwrites:

>On 9 Apr 2008 at 16:26, mattia wrote:

>>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

[off-topic explanation deleted]

>
Very well explained. I'm amazed no one has scolded you and told the OP
that the "experts" are down the corridoor second on the left ....

Would it do any good? AT is apparently determined to ignore the fact
that this newsgroup is for discussion of the C programming language.
Of course most of the regulars killfiled him long ago. They might
want to consider unkillfiling him, at least for a while, to see what
he's up to now.

Some of what he's written recently might be valuable *if* it were
posted in an appropriate forum.

Meanwhile, you and your friends continue to make no actual
contribution, preferring to spend your time whining about other
posters.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

mattia wrote:

>
I think that I'll note use __cplusplus unless I'll have to link my
headers with cpp code. That will be my rule. Thanks all for the reply.

If you think there's the remotest chance your C library might be used
with C++, you may as well use the "extern C" wrappers. There's no
cost/impact to C code and you might save you or your users future work.

I always use "extern C" wrappers.

--
Ian Collins.

[Default User]

Walter Roberson wrote:

In article <47***********************@reader4.news.tin.it>,
mattia <ge****@gmail.comwrote:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

This has to do with C++. A C compiler will not defne __cplusplus
and so a C compiler will compile those lines to nothingness.

This form detects that whether the code is being compiled with a C++
compiler, and if it is, wraps extern "C" { } around the block of
code. The meaning of extern "C" { } is specific to C++, and in C++
means that the enclosed block of code is to have its functions
compiled with C calling sequences rather than C++ calling sequences.
The single most important difference between C calling sequences and
C++ calling sequences is that C++ calling sequences (usually) have
a hidden parameter named "this" that refers to the object being
operated upon; using this syntax in C++ tells C++ to not put in
that hidden parameter, thus leaving the functions defined suitable for
calling from C (or, alternately, -declaring- functions as being
external functions that need C-style parameters to call.)

What? No. extern "C" is a linkage specification. It usually means that
it won't use name-mangling, but the specifics aren't spelled out in the
C++ standard. What it says (in part):

Every implementation shall provide for linkage to functions written
in the C programming language, "C", and linkage to C++ functions,
"C++". [Example:
complex sqrt(complex); // C + + linkage by default
extern "C" {
double sqrt(double); // C linkage
}
-end example]

Brian

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 09/04/08 17:41:

>mattia said:

>>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

No it does not.

Yes, it does.

It is generally used in the header when the library is
written in C but might be called from C++.

See?

Anyway, I know this view won't be a popular one but, in my view, mixing C
and C++ like this in a translation unit that is intended to be seen by a C
compiler is a mistake.

>Best avoided.

No, best used when it is appropriate.

On the contrary - best avoided. There is an alternative, trivial, technique
that does not involve altering the C source to suit C++, yet which suits
C++ perfectly.

For more discussion about this the correct place would be comp.lang.c++

It depends on whether you want to talk about C++ (which I don't), or about
the advisability or otherwise of introducing illegal code into a C
translation unit, protected only by preprocessor directives. I fail to see
why that's topical in comp.lang.c++, given that it's a question about a C
translation unit.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>mattia said:

>>I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

Utter nonsense.

Hmmm.

So are you saying the authours of all my system headers
didn't know which language they're writing in?

Are /you/ saying they've introduced illegal syntax into C translation
units, protected only by a #ifdef of a symbol for which the Standard
defines no meaning and on which C90 imposes no special conditions?

If so, then yes, I'd say they didn't know which language they were writing
in.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Dann Corbit]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:dt******************************@bt.com...

Flash Gordon said:

>Richard Heathfield wrote, On 09/04/08 17:41:

>>mattia said:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

No it does not.

Yes, it does.

>It is generally used in the header when the library is
written in C but might be called from C++.

See?

Anyway, I know this view won't be a popular one but, in my view, mixing C
and C++ like this in a translation unit that is intended to be seen by a C
compiler is a mistake.

>>Best avoided.

No, best used when it is appropriate.

On the contrary - best avoided. There is an alternative, trivial,
technique
that does not involve altering the C source to suit C++, yet which suits
C++ perfectly.

>For more discussion about this the correct place would be comp.lang.c++

It depends on whether you want to talk about C++ (which I don't), or about
the advisability or otherwise of introducing illegal code into a C
translation unit, protected only by preprocessor directives. I fail to see
why that's topical in comp.lang.c++, given that it's a question about a C
translation unit.

From ISO/IEC 9899:1999 (E) Section 6.10.9 (Language) page 161 we have this:
"5 The implementation shall not predefine the macro _ _cplusplus, nor shall
it define it in any standard header."


** Posted from http://www.teranews.com **

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>Richard Heathfield wrote:

>>mattia said:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?
It means that someone hasn't decided which language they're writing in.

Utter nonsense.

Hmmm.

>So are you saying the authours of all my system headers
didn't know which language they're writing in?

Are /you/ saying they've introduced illegal syntax into C translation
units, protected only by a #ifdef of a symbol for which the Standard
defines no meaning and on which C90 imposes no special conditions?

In all but one header, no. They are simply informing C++ compilers that
the C standard library function have C linkage. No illegal syntax there.

The exception is in <string.h>, where C++ adds overloads for the broken
C library functions (strchr() for example) that return a char* to a
const char* argument.

If so, then yes, I'd say they didn't know which language they were writing
in.

If so, they most certainly did.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

<snip>

>>

>>So are you saying the authours of all my system headers
didn't know which language they're writing in?

Are /you/ saying they've introduced illegal syntax into C translation
units, protected only by a #ifdef of a symbol for which the Standard
defines no meaning and on which C90 imposes no special conditions?

In all but one header, no. They are simply informing C++ compilers

This is comp.lang.c, where we discuss C, not C++. Do /you/ know what
language you're writing in? :-)

that
the C standard library function have C linkage. No illegal syntax there.

The syntax

extern "C"

is illegal *C*. If you want to discuss whether it's legal C++, I suggest
you raise the matter in comp.lang.c++ - but here in comp.lang.c, it's
illegal. In C, extern takes a declaration, not a string literal.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Dann Corbit said:

>"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:dt******************************@bt.com...

>>Flash Gordon said:

<snip>

>>>For more discussion about this the correct place would be comp.lang.c++
It depends on whether you want to talk about C++ (which I don't), or
about the advisability or otherwise of introducing illegal code into a C
translation unit, protected only by preprocessor directives. I fail to
see why that's topical in comp.lang.c++, given that it's a question
about a C translation unit.

From ISO/IEC 9899:1999 (E) Section 6.10.9 (Language) page 161 we have
this: "5 The implementation shall not predefine the macro _ _cplusplus,
nor shall it define it in any standard header."

Right. And it's in a reserved namespace, too. So why bother testing for it?

It's in the implementation's namespace, so the the "implementation" is
free to define it. The "implementation" might not be a C compiler.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

<snip>

[__cplusplus is] in the implementation's namespace, so the the
"implementation" is free to define it.

Not if it's a C99 implementation. And a C90 implementation is free to
define it to mean anything it likes.

The "implementation" might not be a C compiler.

In which case it's hardly relevant in comp.lang.c (unless, of course, it's
a C interpreter).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

<snip>

>[__cplusplus is] in the implementation's namespace, so the the
"implementation" is free to define it.

Not if it's a C99 implementation.

C99? I thought you were posting from the past :)

And a C90 implementation is free to define it to mean anything it likes.

Indeed it is, but such an implementation wouldn't be very popular in a
hosted environment, would it?

--
Ian Collins.

[Ian Collins]

Richard Heathfield wrote:

>
It is in fact unfortunate, rather than otherwise. There is, after all, a
very easy way to do this that allows C++ access to C headers very
conveniently, *without* polluting the C code base.

In isolation, yes. But things soon turn nasty when a nested (system)
include has its own wrapper.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

<snip>

>>[__cplusplus is] in the implementation's namespace, so the the
"implementation" is free to define it.

Not if it's a C99 implementation.

C99? I thought you were posting from the past :)

I did say "if". :-) But I also used the present tense to describe a C99
implementation, which would suggest, if anything, that I'm posting from
the future!

>And a C90 implementation is free to define it to mean anything it likes.

Indeed it is, but such an implementation wouldn't be very popular in a
hosted environment, would it?

I don't see why not. I'd have no problem using such an implementation - not
even when including C headers in C++ code. (That's because, if I want to
do such a thing, I will write (actually, generate - it's trivial to do) a
cppfoo header which looks like this:

#ifndef H_CPP_FOO
#define H_CPP_FOO 1
extern "C"
{
#include "foo.h"
};

#endif

and then #include "cppfoo" in the C++ code.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>C99? I thought you were posting from the past :)

I did say "if". :-) But I also used the present tense to describe a C99
implementation, which would suggest, if anything, that I'm posting from
the future!

So it's you who nicked my Tardis!

(That's because, if I want to
do such a thing, I will write (actually, generate - it's trivial to do) a
cppfoo header which looks like this:

#ifndef H_CPP_FOO
#define H_CPP_FOO 1
extern "C"
{
#include "foo.h"
};

#endif

and then #include "cppfoo" in the C++ code.

As I said elsethread, this woks in isolation but craps out of foo.h
includes a header with its own wrapper.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

<snip>

>>
#ifndef H_CPP_FOO
#define H_CPP_FOO 1
extern "C"
{
#include "foo.h"
};

#endif

and then #include "cppfoo" in the C++ code.

As I said elsethread, this woks in isolation but craps out of foo.h
includes a header with its own wrapper.

But why should it? foo.h is a C header! If it includes a "header with its
own wrapper", it's breaking the model. Being a C header, it should only
include other C headers.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>Richard Heathfield wrote:

<snip>

>>#ifndef H_CPP_FOO
#define H_CPP_FOO 1
extern "C"
{
#include "foo.h"
};

#endif

and then #include "cppfoo" in the C++ code.

As I said elsethread, this woks in isolation but craps out of foo.h
includes a header with its own wrapper.

But why should it? foo.h is a C header! If it includes a "header with its
own wrapper", it's breaking the model. Being a C header, it should only
include other C headers.

C standard library headers are also C++ standard library headers. I'm
not aware of any hosted environment that does not use the same files for
both.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

>>Richard Heathfield wrote:

<snip>

<crunch>

>>>#ifndef H_CPP_FOO/#define H_CPP_FOO 1/extern "C"
{/#include "foo.h"/};/#endif

</crunch>

>>>>
and then #include "cppfoo" in the C++ code.

As I said elsethread, this woks in isolation but craps out of foo.h
includes a header with its own wrapper.

But why should it? foo.h is a C header! If it includes a "header with
its own wrapper", it's breaking the model. Being a C header, it should
only include other C headers.

C standard library headers are also C++ standard library headers.

Standard library headers can (ab)use the "as-if" rule to do what they like
as long as it all works. I was under the impression that we were
discussing non-implementation headers.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Peter Nilsson said:

[...]

>The syntax is perfectly valid, see 6.10.1p6.

Neither my C89 draft nor the C99 standard /has/ a 6.10.1p6. C99 stops at
6.10.1p5.

N1256 adds a paragraph. N1256 6.10.1p6 is identical to C99 6.10.1p5.

Besides, section 6.10.1 of C99 is about conditional inclusion, and I'm not
talking about that - I'm talking about extern "C", which is nothing to do
with the preprocessor. The grammar requires extern to be followed by a
type-specifier, type-qualifier, function-specifier, or
init-declarator-list. Not a string literal. The only reason the
preprocessor is relevant here is that it's the only thing standing in the
way of a diagnostic message.

/* void *p = 42; */

The comment delimiters are the only thing standing in the way of a
diagnostic message. Oh no!

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>The grammar requires extern to be followed
by a type-specifier, type-qualifier, function-specifier, or
init-declarator-list. Not a string literal. The only reason the
preprocessor is relevant here is that it's the only thing standing in
the way of a diagnostic message.

/* void *p = 42; */

The comment delimiters are the only thing standing in the way of a
diagnostic message. Oh no!

Well, Keith, that's very droll, but preprocessor directives are not
comments. Whenever we see a #ifdef, we must consider what will happen if
the macro *is* defined, and what will happen if it is *not* defined. In
this case, if the macro *is* defined, the resulting translation unit is
not legal C. And there's no requirement for conforming C90 implementations
to avoid defining __cplusplus (for whatever reason). So the code isn't
safe.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Richard Heathfield wrote, On 09/04/08 23:01:

Ian Collins said:

>Richard Heathfield wrote:

>>Ian Collins said:

<snip>

>>>So are you saying the authours of all my system headers
didn't know which language they're writing in?
Are /you/ saying they've introduced illegal syntax into C translation
units, protected only by a #ifdef of a symbol for which the Standard
defines no meaning and on which C90 imposes no special conditions?

In all but one header, no. They are simply informing C++ compilers

This is comp.lang.c, where we discuss C, not C++. Do /you/ know what
language you're writing in? :-)

Yes. Do you know of ANY C compiler that defines __cplusplus, or any
reason why one would. Do you know that in C99 C ompilers are required to
*not* define it?

>that
the C standard library function have C linkage. No illegal syntax there.

The syntax

extern "C"

is illegal *C*. If you want to discuss whether it's legal C++, I suggest
you raise the matter in comp.lang.c++ - but here in comp.lang.c, it's
illegal. In C, extern takes a declaration, not a string literal.

Now fine an implementation where
#ifdef __cplusplus
extern "C"
#endif

is illegal syntax. That is the entire block, not one part of it taken in
isolation.
--
Flash Gordon

[Flash Gordon]

Richard Heathfield wrote, On 10/04/08 01:15:

Keith Thompson said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>The grammar requires extern to be followed
by a type-specifier, type-qualifier, function-specifier, or
init-declarator-list. Not a string literal. The only reason the
preprocessor is relevant here is that it's the only thing standing in
the way of a diagnostic message.

/* void *p = 42; */

The comment delimiters are the only thing standing in the way of a
diagnostic message. Oh no!

Well, Keith, that's very droll, but preprocessor directives are not
comments.

No, but when you know the symbol will never be defined on a C compiler
they have pretty much the same effect.

Whenever we see a #ifdef, we must consider what will happen if
the macro *is* defined, and what will happen if it is *not* defined. In
this case, if the macro *is* defined, the resulting translation unit is
not legal C. And there's no requirement for conforming C90 implementations
to avoid defining __cplusplus (for whatever reason). So the code isn't
safe.

There is, however, a requirement for a conforming C99 implementation to
avoid defining it (and C99 *is* topical here as well as C89), and there
are excellent reasons why non-C99 implementations do not define it. So
much so that unless someone has created an implementation for the
specific purpose of breaking such code you will never find one, and if
you do send me the address of a pub plus a date and time and I will go
there and buy you a pub! (it's up to you to get yourself to said pub,
I'm only buying you the pint)
--
Flash Gordon

[Kenneth Brody]

Richard Heathfield wrote:

>
Ian Collins said:

Richard Heathfield wrote:

mattia said:

I've see in some code:

#ifdef __cplusplus
extern "C"
{
#endif

what does it mean?

It means that someone hasn't decided which language they're writing in.

Utter nonsense.

Hmmm.

So are you saying the authours of all my system headers
didn't know which language they're writing in?

Are /you/ saying they've introduced illegal syntax into C translation
units, protected only by a #ifdef of a symbol for which the Standard
defines no meaning and on which C90 imposes no special conditions?

The system header files supplied by one implementation are under no
obligation to with in another implementation.

Are you saying that the system header files, which were supplied
by the writers of this particular implementation, don't know that
they will not define __cplusplus themselves? And, isn't the name
"__cplusplus" in reserved namespace, meaning that others aren't
allowed to define it, either?

Yes, the implementors could define "__cplusplus", but then they
probably wouldn't be using it to block out C++ syntax that they
chose to include.

Just because C90 doesn't impose any special conditions on that name
doesn't mean that the implementors can't decide to use something
from a different standard, as long as it doesn't interfere with C.

If so, then yes, I'd say they didn't know which language they were writing
in.

I think they knew what language they were writing in, a simply
chose to say "we want to make it easy for other people to use this
in C++ as well".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Richard Heathfield wrote:
[... snip "#ifdef __cplusplus" example ...]

$ gcc -D__cplusplus=1 -W -Wall -ansi -pedantic -Wformat-nonliteral

[...snip resulting errors ...]
[...]

Note that the C source code *does not* invade implementation namespace by
defining __cplusplus - it just checks to see whether it is defined. The C
source really is C source, apart from the extern "C" additions. The
invocation is of an ISO C90 implementation in conforming mode. It sure
looks to me like that extern "C" caused no end of problems - in C code.

But, haven't _you_ "invaded implementation namespace" by telling the
compiler to define __cplusplus, even if it's not in "the C source
code"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Tobin]

In article <47**************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>$ gcc -D__cplusplus=1 -W -Wall -ansi -pedantic -Wformat-nonliteral

[...snip resulting errors ...]

>But, haven't _you_ "invaded implementation namespace" by telling the
compiler to define __cplusplus, even if it's not in "the C source
code"?

Richard will presumably argue that he is treating gcc+arguments as
the implementation. He could stick it all in a shell script and
call it "RH's C Compiler".

But this whole argument is silly. A conforming C90 implementation
could define __cplusplus, but it would be a stupid implementation and
people would reject it. You can find a whole host of things that the
standard doesn't prohibit, but which would make a compiler a laughing
stock.

-- Richard
--
:wq

[Kenneth Brody]

Richard Tobin wrote:
[...]

But this whole argument is silly. A conforming C90 implementation
could define __cplusplus, but it would be a stupid implementation and
people would reject it. You can find a whole host of things that the
standard doesn't prohibit, but which would make a compiler a laughing
stock.

Well, one could make an implementation to "stress test" C source code,
with things like making NULL not all-bits zero (perhaps even making
an all-bits-zero pointer a trap representation), converting between
pointers and ints/longs and back resulting in invalid pointers, (is
it valid to have sizeof(void*) sizeof(long)?), returning pointers
in a different register than non-pointers, and so on.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Tobin]

In article <47**************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>But this whole argument is silly. A conforming C90 implementation
could define __cplusplus, but it would be a stupid implementation and
people would reject it. You can find a whole host of things that the
standard doesn't prohibit, but which would make a compiler a laughing
stock.

>Well, one could make an implementation to "stress test" C source code,
with things like making NULL not all-bits zero (perhaps even making
an all-bits-zero pointer a trap representation), converting between
pointers and ints/longs and back resulting in invalid pointers, (is
it valid to have sizeof(void*) sizeof(long)?), returning pointers
in a different register than non-pointers, and so on.

Some of those tests are, to some degree, plausible. There could be
some reason for some system to behave like that. Some are less so.
There are even more absurd possiblities, such as only accepting one
particular program that reaches the various minimum implementation
limits. Having a C90 implementation define __cplusplus is in the
"completely absurd" category; no realistic implementation would do it
on any platform, so there is no point having a stress test for it.

It makes no more sense to write your program to accommodate such
implementations than to allow for ones where addition sometimes
doesn't work.

-- Richard

--
:wq

[lawrence.jones]

Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

>
Having a C90 implementation define __cplusplus is in the
"completely absurd" category; no realistic implementation would do it
on any platform, so there is no point having a stress test for it.

You'd think so, but back in the day, there was at least one real
commercial compiler that #define'd __STDC__ as 1 before making *amy*
other change required to conform to the ANSI C Standard! So equally
strange things have happened.

-Larry Jones

It must be sad being a species with so little imagination. -- Calvin