473,320 Members | 1,952 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

ifdefs


# 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
16 1455
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
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

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

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

"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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

20
by: jvankay | last post by:
Does any C guru out there know of a C pre-processing tool that will allow limited pruning of C source based on a single #define variable. That is, in the code fragment below: XXX #ifdef...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.