«

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.

Antoninus Twink <> writes:

> 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 ....

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.

In article <>,
Antoninus Twink <> wrote:
>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()?

(Kenny McCormack) writes:

> In article <>,
> Antoninus Twink <> wrote:
>>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()?

aaargh! Did you cast malloc?

<Martin Ambuhl voice>Thats bullshit and I wont read any more. We don't
deal with morons here</snotty ego maniac voice>

Richard <devr_@gmail.com> writes:
> Antoninus Twink <> writes:
>> 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) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"