Is it a good thing that program mix C and C++?

[Ian Collins]

Ian Collins said:


I can find no evidence in ISO/IEC 9899 to support your claim - or, for
that matter, my own claim that it makes C functions callable from C++.
I therefore withdraw that claim. Please provide chapter and verse from
ISO/IEC 9899 for extern "C" being a mechanism to C++ functions callable
from C, or alternatively follow my lead by withdrawing your claim.

That's almost as daft as asking me to show where ISO/IEC 9899 states
that the sky is blue.

 

[user923005]

# Ian Collins wrote:
# > CBFalconer wrote:
# >> dolphin wrote:

# >>
# >>> Is it a good thing that program mix C and C++?
# >>
# >> Mix, no. You can call C routines from C++, but not the reverse.
# >
# > No so, C++ provides a mechanism (the extern "C" linkage specifier)
# > to make C++ functions callable from C.
#
# That makes C callable from C++. Not the reverse.

That comes as a real shock to those of us who do so, by deviously
following the extern "C" rules explicitly intended to allow this.

Albeit at great danger in either case.

For instance, you cannot mix try/catch with setjmp()/longjmp().
Are you absolutely certain that setjmp()/longjmp() are not used
anywere in the C routines (including library calls)?
How about try/catch?

There are other dangers as well.

 

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

Please provide chapter and
verse from ISO/IEC 9899 for extern "C" being a mechanism to [make]
C++ functions callable from C, or alternatively follow my lead by
withdrawing your claim.

That's almost as daft as asking me to show where ISO/IEC 9899 states
that the sky is blue.

And indeed, as I look out of my window, I see that the sky is not blue.
It's quite a deep black, actually.

Had ISO/IEC 9899 guaranteed the blueness of the sky, I would have had
cause for complaint about non-conformance. As it doesn't offer any such
guarantee, however, I fail to see the relevance of your objection.

 

[CBFalconer]

It's a two way street.

No it isn't. The C++ compiler does various unspeakable things to
the function names in order to handle overloading, i.e. it creates
multiple names for functions depending on the types of their
parameters. It calls these functions with similarly adorned
names. This is all necessary to make C++ work. A C header file
can conditionally (on __cplusplus) include the extern "C" { .... }
wrapper on the function prototypes, which tells the C++ compiler
that these calls are unadorned. Now the linker can work.

Since the C++ object code uses those adorned names, the C compiler
has no way of generating calls to them. If you try to compile the
C code with a C++ compiler you have other problems, because they
are different languages.

 

[Ian Collins]

Ian Collins said:

Richard Heathfield wrote:

Please provide chapter and
verse from ISO/IEC 9899 for extern "C" being a mechanism to [make]
C++ functions callable from C, or alternatively follow my lead by
withdrawing your claim.

That's almost as daft as asking me to show where ISO/IEC 9899 states
that the sky is blue.

And indeed, as I look out of my window, I see that the sky is not blue.
It's quite a deep black, actually.

Had ISO/IEC 9899 guaranteed the blueness of the sky, I would have had
cause for complaint about non-conformance. As it doesn't offer any such
guarantee, however, I fail to see the relevance of your objection.

There is a world beyond ISO/IEC 9899, so just as ISO/IEC 9899 doesn't
guarantee the blueness of the sky, it doesn't say anything regarding how
other languages make their functions callable from C.

 

[Richard Heathfield]

Ian Collins said:

There is a world beyond ISO/IEC 9899

Chapter and verse, please.

 

[Ian Collins]

Ian Collins said:




Chapter and verse, please.

We are still waiting for the first draft of the ISO "Life, the Universe
and Everything" specification. I'll get back to you when it is released....

 

[Richard Tobin]

Chapter and verse, please.

[/QUOTE]

We are still waiting for the first draft of the ISO "Life, the Universe
and Everything" specification. I'll get back to you when it is released....

There was a W3C specification for this, but it never got past the
Candidate Recommendation stage because of the lack of two compatible
implementations.

-- Richard

 

[Keith Thompson]

Ian Collins said:

Ian Collins said:
CBFalconer wrote: [...]
Mix, no. You can call C routines from C++, but not the reverse.

No so, C++ provides a mechanism (the extern "C" linkage specifier) to
make C++ functions callable from C.

No, it doesn't. It makes C functions callable from C++.

All together now: oh yes it does!

I can find no evidence in ISO/IEC 9899 to support your claim - or, for
that matter, my own claim that it makes C functions callable from C++.
I therefore withdraw that claim. Please provide chapter and verse from
ISO/IEC 9899 for extern "C" being a mechanism to C++ functions callable
from C, or alternatively follow my lead by withdrawing your claim.

The lack of any mention of this in ISO/IEC 9899 indicates that the
claim is off-topic. It does not indicate that it should be withdrawn,
<OT>particularly since the claim happens to be correct</OT>.
Withdrawing a claim tends to imply that it's untrue, not merely that
it should not have been made.

If your call to withdraw the claim was not intended to imply that the
claim is untrue, then I have no argument (except for your potentially
misleading choice of words).

 

[Ian Collins]

No it isn't. The C++ compiler does various unspeakable things to
the function names in order to handle overloading, i.e. it creates
multiple names for functions depending on the types of their
parameters. It calls these functions with similarly adorned
names. This is all necessary to make C++ work. A C header file
can conditionally (on __cplusplus) include the extern "C" { .... }
wrapper on the function prototypes, which tells the C++ compiler
that these calls are unadorned. Now the linker can work.

extern "C" linkage suppresses name mangling for functions compiled as
C++. The rules of C++ permit only one instance of any extern "C"
function name, they can not be overloaded and they can be called from C.

Since the C++ object code uses those adorned names, the C compiler
has no way of generating calls to them.

It dose if they are declared extern "C" because the functions are not
mangled.

 

[Sheth Raxit]

one can call c from c++, and viceversa.

i was 'technically' wrong, but i think effect is almost same.

 

[Bill Reid]

here.

It's considered bad practice, as it can hide a missing #include for
the malloc-and-friends prototypes. Without those prototypes, all
bets are off as to what happens when the compiler takes what it
thinks is an int return and casts it into your pointer.

Yeah, yeah, yeah, but interestingly apropos to the original question,
if you should for some reason decide to use malloc() instead of new()
in a C++ program, you MUST cast the return value. If you don't,
you'll get a compiler error! (Which happens for many of the "little"
differences between C types, standard libraries, and semantics
when used in a C++ program.)

And of course, it is exactly this required explicit typing of return
values in C++ that precludes all the "horrible" problems (which
only occur if you make another ACTUAL mistake) of NOT casting
the value in C!

But like the use of extern "C", this is not just off-topic, but beyond
the scope of knowledge of many of the frequent posters here, as
evidenced by their struggle in this thread to come to grips with
some simple realities of real-world programming as it is and was
performed at any time in the last 15 years or so...

 

[Pierre Asselin]

No it isn't. The C++ compiler does various unspeakable things to
the function names [ ... ]

The <<extern "C">> construct of C++ allows the programmer to
write C++ functions that are callable from C. That's a fact.

You can also write C++ functions that are not callable from C. So
what. To use such functions in a C program you have to write a
wrapper, necessarily in C++, that *is* callable from C.

It's not just a name mangling issue, the ABI's can be different
and that comes up when passing a C++ function pointer to a C library
that wants a callback.

To the OP: you can mix your C and C++ exactly as you would mix C
and, say, Fortran. Treat them as distinct languages and do what
you have to do to create working interlanguage bindings.

 

[CBFalconer]

.... snip ...

Yeah, yeah, yeah, but interestingly apropos to the original question,
if you should for some reason decide to use malloc() instead of new()
in a C++ program, you MUST cast the return value. If you don't,
you'll get a compiler error! (Which happens for many of the "little"
differences between C types, standard libraries, and semantics
when used in a C++ program.)

Did you by any chance ever note the name of this newsgroup? If so,
will you kindly explain to me (and others) where in it the
character sequence "++" appears?

 

[Bill Reid]

Did you by any chance ever note the name of this newsgroup? If so,
will you kindly explain to me (and others) where in it the
character sequence "++" appears?

Nowhere! Which is why I am concerned about the topicality of
this previous post in this thread:

Date: Wed, 28 Mar 2007
From: CBFalconer <[email protected]>
Newsgroups: comp.lang.c
Subject: Re: Is it a good thing that program mix C and C++?

Is it a good thing that program mix C and C++?

Mix, no. You can call C routines from C++, but not the reverse.



---end of archived post

Actually, I'm not that concerned about the dreaded "++" as much
as the fact that it was just technically incorrect. Bad information is
ALWAYS off-topic in any group AFAIC...

So my advice is to stick with what you know. If you don't know
much, don't post much, or honestly ask for help from people who
do know. Simple enough?

 

[Kenny McCormack]

Did you by any chance ever note the name of this newsgroup? If so,
will you kindly explain to me (and others) where in it the
character sequence "++" appears?

Nowhere! Which is why I am concerned about the topicality of
this previous post in this thread:

Date: Wed, 28 Mar 2007
From: CBFalconer <[email protected]>
Newsgroups: comp.lang.c
Subject: Re: Is it a good thing that program mix C and C++?

Is it a good thing that program mix C and C++?

[/QUOTE]

(And, again, poor, misunderstood CBF wrote)

Mix, no. You can call C routines from C++, but not the reverse.

See, that's really the problem with being so anal about the topicality
nonsense. You can't help but eventually become hoist on your own petard.

But, of course, the regs get around this by implicitly (and from time to
time, explicitly, as in the recent fracas where good ole Heathfield
started posting a bunch of wildly OT crud) having different rules for
the regs than for the hoi polloi.

Actually, I'm not that concerned about the dreaded "++" as much
as the fact that it was just technically incorrect. Bad information is
ALWAYS off-topic in any group AFAIC...

So my advice is to stick with what you know. If you don't know
much, don't post much, or honestly ask for help from people who
do know. Simple enough?

Good advice. But following it would mean the death of this (very
entertaining) newsgroup. We can't have that.

 

[Malcolm McLean]

Well said, sir! And, you might add, the ethics of casting the return
value of malloc().

Note (for the uninitiated): The "casting the return value of malloc()"
thing is an idea that is taken as gospel around here, but has no real
world traction outside of this NG. It is certainly possible to disagree
with this bit of dogma, but doing so will win you no friends around here.

I was converted to uncast malloc() by the ng. Not for the reason given -
that it can mask failure to include stdlib.h. In production code that just
can't happen. My reason was to reduce visual clutter, and because a C
function only rarely needs to be cut and pasted into C++.

 

[Kenny McCormack]

I was converted to uncast malloc() by the ng. Not for the reason given -
that it can mask failure to include stdlib.h. In production code that just
can't happen. My reason was to reduce visual clutter, and because a C
function only rarely needs to be cut and pasted into C++.

Agreed on all counts. The "mask failure" arguement is particularly
weak. It is very similar to the "if (1 == a) rather than if (a == 1)"
thing, where, this may have had some traction at some point in the deep
dark past, but nowadays any compiler worth 2 bits will catch it (i.e.,
warn about it) anyway.

The point is that is you consider the following three commonly harped on
things in this NG:

1) char a[10]; x = a[10];
2) void main()
3) char *x = (char *) malloc(10);

The first is clearly an error. The 2nd probably, and the third, really not.
Yet all three are harped upon with equal vigor, by a bunch of freaks who
don't understand the concept of degree.

 

[Martin Golding]

I was converted to uncast malloc() by the ng. Not for the reason given -
that it can mask failure to include stdlib.h. In production code that
just can't happen.

I have corrected a live, delivered, customer-affecting bug in 'production
code' caused by failure to include stdlib.h, masked by casting the return
from malloc. "Just can't happen" is thereby proven to be something of an
exaggeration. To the (reasonable) argument "but it must have been
seriously inexperienced programmers", I point out that's _exactly_
the audience for "Don't Cast Malloc()".

As for C++, should we not be recommending <OT> use new() <OT>?

Martin

 

[Richard Heathfield]

Malcolm McLean said:

I was converted to uncast malloc() by the ng. Not for the reason given
- that it can mask failure to include stdlib.h. In production code
that just can't happen.

When "just can't happen" relies on a basic level of human competence, we
can count on it happening at least 17 times a day, 260 days a year.