By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,404 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,404 IT Pros & Developers. It's quick & easy.

ifdefs

P: n/a

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);
# ifdef __cplusplus
}
# endif
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int *rt, *qt;
qt = get_an_int();
rt = pass_pointer_triv(qt);
printf ("t is %d\n", *rt);
free(rt);
return 0;
}

int * get_an_int(void)
{
int t;
int * pt;
pt = malloc (sizeof*pt);
t = 41;
pt[0] = t;
return pt;
}

int * pass_pointer_triv(int *a)
{
int t;
t = (*a) ++;
printf("t is %d\n", t);
return a;
}
/* end source */
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall? furunculus
Jun 22 '06 #1
Share this Question
Share on Google+
16 Replies


P: n/a
Your Uncle said:
# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);
# ifdef __cplusplus
}
# endif
<snip>
int * pt;
pt = malloc (sizeof*pt);
t = 41;
pt[0] = t;
If malloc failed, the behaviour of this assignment is undefined.
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?


Nothing whatsoever, as far as comp.lang.c is concerned. The #ifdefs,
#endifs, and the stuff in between them are all of no consequence and can be
omitted without affecting the semantics of your C program in any way.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 22 '06 #2

P: n/a
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
# ifdef __cplusplus
extern "C" {
# endif int * get_an_int(void);
int * pass_pointer_triv(int *); # ifdef __cplusplus
}
# endif [...]
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?
If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

#include <stdio.h>
#include <stdlib.h> int * pass_pointer_triv(int *a)
{
int t;
t = (*a) ++;
printf("t is %d\n", t);
return a;
}


Just to check: did you intend that pass_pointer_triv have
the side effect of incrementing that integer at the location
pointed to, and that that increment be done *after* the value
to be printed was determined? e.g., that (say) 5 would be
printed but afterwards the pointer would point to the value 6 ?
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Jun 22 '06 #3

P: n/a

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:e7**********@canopus.cc.umanitoba.ca...
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif

[...]
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?


If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

I refuse to believe that linkage between c and c++ is OT in either forum,
given that it isn't a preamble to some silly holy war. The OP lacks the
requisite bloodlust.
#include <stdio.h>
#include <stdlib.h>

int * pass_pointer_triv(int *a)
{
int t;
t = (*a) ++;
printf("t is %d\n", t);
return a;
}


Just to check: did you intend that pass_pointer_triv have
the side effect of incrementing that integer at the location
pointed to, and that that increment be done *after* the value
to be printed was determined? e.g., that (say) 5 would be
printed but afterwards the pointer would point to the value 6 ?

I got the return I was looking for on my own silly implementation. cheers,
f
Jun 22 '06 #4

P: n/a
In article <sq********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Your Uncle said:
# ifdef __cplusplus
extern "C" {
# endif int * get_an_int(void);
int * pass_pointer_triv(int *); # ifdef __cplusplus
}
# endif This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?

Nothing whatsoever, as far as comp.lang.c is concerned. The #ifdefs,
#endifs, and the stuff in between them are all of no consequence and can be
omitted without affecting the semantics of your C program in any way.


Just to be a pest ;-)
-Potentially- something in the C implementation could define
__cplusplus [I think -- "reserved for any use" allows implementation
use, right?]. It'd be a strange thing to do, but if it happened
then the semantics of the C program would indeed be affected. ;-)
--
Programming is what happens while you're busy making other plans.
Jun 22 '06 #5

P: n/a
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:e7**********@canopus.cc.umanitoba.ca...
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
# ifdef __cplusplus
extern "C" {
# endif
The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary:
I refuse to believe that linkage between c and c++ is OT in either forum,
given that it isn't a preamble to some silly holy war.


Well, what I should perhaps have said is,
"The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not this newsgroup, but as a quick summary:"

The -existance- of C++ is effectively off-topic for comp.lang.c .
There might be other C newsgroups that deal with C++ as well as C,
but comp.lang.c doesn't.

Discussing the linkage between C and C++ requires a good knowledge of
C++ linkage, which is not something that is specified in any C
standard.

Indeed, the details of C linkage are not specified in any
C standard, so comp.lang.c doesn't even deal with with linking
C to C, beyond the various restrictions on variable names, the
meaning of "extern", and the implied promise of the C standard that
the implementation will provide *some* linkage mechanism.

In C++, does declaring a function to have C linkage change the
default promotions for that function? You can't talk about
the linkage between C and C++ until you can answer that question,
and you can't answer that question without knowing the details of
C++'s promotion rules, which are different from C's, and C++'s
promotion rules are not specified by the C standards.

Thus in order to discuss the linkage between C and C++ one would have
to enter into a detailed cross-comparison of C and C++ language
features. Which we are not going to do. And if you "refuse to believe"
that, then you will likely find the experience akin to that
of a Flat Earth Society member attending an Astronomy convention.
--
All is vanity. -- Ecclesiastes
Jun 22 '06 #6

P: n/a
Walter Roberson wrote:
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif

[...]
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?


If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.


I'm pretty sure C++ non-member functions never have a hidden "this"
parameter. It is indeed OT here regardless, so a C++ group, as you
suggested, would clear it up properly.

Jun 22 '06 #7

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif

[...]

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.


<OT>
Not in this case. "this" would used in C++ functions declared as class
methods.
This is definitively implementation dependent, but in most cases the
"extern C" modifier means that the function names will not be
modified, ("mangled",) to provide type-safe linkage using a
conventional linker.

I.e., if __cplusplus is not defined, the object file will use the
following symbols for each function:

int * get_an_int(void); ---> _get_an_int
int * pass_pointer_triv(int *); ---> _pass_pointer_triv

If __cplusplus is defined, g++ (3.2.2/Linux) will generate the
following:

int * get_an_int(void); ---> _Z10get_an_intv
int * pass_pointer_triv(int *); ---> _Z17pass_pointer_trivPi

</OT>
Jun 22 '06 #8

P: n/a
I wrote:
<OT>
Not in this case. "this" would used in C++ functions declared as class
methods.
This is definitively implementation dependent, but in most cases the
"extern C" modifier means that the function names will not be
modified, ("mangled",) to provide type-safe linkage using a
conventional linker.

I.e., if __cplusplus is not defined, the object file will use the
following symbols for each function:

int * get_an_int(void); ---> _get_an_int
int * pass_pointer_triv(int *); ---> _pass_pointer_triv

If __cplusplus is defined, g++ (3.2.2/Linux) will generate the
following:

int * get_an_int(void); ---> _Z10get_an_intv
int * pass_pointer_triv(int *); ---> _Z17pass_pointer_trivPi

That is wrong. Trying again...

* Using a C compiler __cplusplus is not (should not be?) defined and
the extern "C" is ignored.

* Using a C++ compiler, __cplusplus is defined, and the extern "C"
causes the compiler to process the declarations as before. (This
allows calling them from C code.)

* Using a C++ compiler *without* the #ifdefs produces the "mangled"
symbols, usable from C++ but not directly callable from C.
</OT>

Jun 22 '06 #9

P: n/a

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:e7**********@canopus.cc.umanitoba.ca...
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:e7**********@canopus.cc.umanitoba.ca...
In article <44***********************@news.usenetmonster.com> ,
Your Uncle <in*****@crippled.net> wrote:# ifdef __cplusplus
extern "C" {
# endif The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary:
I refuse to believe that linkage between c and c++ is OT in either forum,
given that it isn't a preamble to some silly holy war.


Well, what I should perhaps have said is,
"The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not this newsgroup, but as a quick summary:"

<snip>
Dankenstein condemns this OT talk.
Thus in order to discuss the linkage between C and C++ one would have
to enter into a detailed cross-comparison of C and C++ language
features. Which we are not going to do. And if you "refuse to believe"
that, then you will likely find the experience akin to that
of a Flat Earth Society member attending an Astronomy convention.

The choice of spacio-temporal origin is arbitrary. Why, since lines were
curved for Euclid, would the adjective "flat" not suffice for him? Thanks
for posting something that needed to be snipped. cheers, f
--------
Von Kohelet will geredet werden?
Jun 22 '06 #10

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
[...]
Just to be a pest ;-)
-Potentially- something in the C implementation could define
__cplusplus [I think -- "reserved for any use" allows implementation
use, right?]. It'd be a strange thing to do, but if it happened
then the semantics of the C program would indeed be affected. ;-)


In C90, theoretically, yes.

In C99, the compiler is specifically forbidden to define the
__cplusplus macro.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 22 '06 #11

P: n/a
Harald van Dijk wrote:
Walter Roberson wrote:

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden
"this" parameter.


I'm pretty sure C++ non-member functions never have a hidden "this"
parameter. It is indeed OT here regardless, so a C++ group, as you
suggested, would clear it up properly.

You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so the
function names aren't usually mangled.

Brian
Jun 22 '06 #12

P: n/a
Default User wrote:
Harald van Dijk wrote:

Walter Roberson wrote:


The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden
"this" parameter.


I'm pretty sure C++ non-member functions never have a hidden "this"
parameter. It is indeed OT here regardless, so a C++ group, as you
suggested, would clear it up properly.


You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so the
function names aren't usually mangled.

Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old systems.

--
Ian Collins.
Jun 22 '06 #13

P: n/a
Ian Collins wrote:
Default User wrote:

You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so
the function names aren't usually mangled.

Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old
systems.

I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.

Brian
Jun 22 '06 #14

P: n/a
Default User wrote:
Ian Collins wrote:

Default User wrote:


You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so
the function names aren't usually mangled.


Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old
systems.


I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.

I thought so I don't remember seeing any reference to name mangling in
the standard, just checking.

Cheers,

--
Ian Collins.
Jun 22 '06 #15

P: n/a
"Default User" <de***********@yahoo.com> writes:
Ian Collins wrote:
Default User wrote:
> You're correct. The "C linkage" means that the symbol won't have
> name-mangling, which is an implementation-specific C++ technique for
> resolving overloaded symbols. Usually this means incorporating the
> argument types in the symbol name. C doesn't have overloading, so
> the function names aren't usually mangled.
>

Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old
systems.


I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.


It's not uncommon for external symbols to have a '_' prepended, or to
be truncated (to 31 characters or more in C99, 6 or more in C90), or
to be mapped to upper or lower case (C90 only). Whether this
constitutes "mangling" is another question.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 22 '06 #16

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Default User" <de***********@yahoo.com> writes:
Ian Collins wrote:
Default User wrote:
> You're correct. The "C linkage" means that the symbol won't have
> name-mangling, which is an implementation-specific C++ technique for
> resolving overloaded symbols. Usually this means incorporating the
> argument types in the symbol name. C doesn't have overloading, so
> the function names aren't usually mangled.
>
Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old
systems.
I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.


It's not uncommon for external symbols to have a '_' prepended, or to
be truncated (to 31 characters or more in C99, 6 or more in C90), or
to be mapped to upper or lower case (C90 only). Whether this
constitutes "mangling" is another question.

The other guys mentioned "mangling" first. As I read it, I recounted Mr.
Sosman's anecdote about a prolific employee.
[possibly unfair snip] We must do something. This is something. Therefore, we must do this.

My guess is that you know 42 volumes on linking c to the other guys. I
don't have an errant syllogism to motivate a response. cheers, f
Jun 23 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.