# 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 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)
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
"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
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.
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
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. 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>
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>
"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? 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.
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
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.
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
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.
"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.
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
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....
|
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...
| |