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

L

Lane Straatman

dolphin said:
Is it a good thing that program mix C and C++?
You might get output more quickly with a Gemisch. Will you offend the True
Believers, absolutely.
 
U

user923005

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

The C++ language includes the standard C libraries. Undoubtably, some
of it is written in C, for almost every instance.

So I think C++ programmers can hardly object.
 
I

Ian Collins

CBFalconer said:
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.
 
S

Sheth Raxit

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

Its depend what all you want to do ?
Are you having some code already available in one lang (or both
lang) ?
do you plan to write user/kernel which code ?
...
...

Nothing is good or bad if used with care and correct usage.



-Raxit
 
S

SM Ryan

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

It is a good thing to get the program finished and running
correctly.
 
R

Richard Heathfield

Ian Collins said:
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++.
 
R

Richard Tobin

Is it a good thing that program mix C and C++?
[/QUOTE]
Mix, no. You can call C routines from C++, but not the reverse.

The C language does not define a mechanism for calling C++ functions,
but it is possible to do so in almost all (if not all) implementations.

-- Richard
 
I

Ian Collins

Richard said:
Ian Collins said:


No, it doesn't. It makes C functions callable from C++.
All together now: oh yes it does!

It's commonly used where a C++ function has to be passed to a C library
as a callback.

extern "C" specified the linkage type of the function, not its language.
 
C

Charlton Wilbur

"SM" == SM Ryan
SM> that program mix C and C++?

SM> It is a good thing to get the program finished and running
SM> correctly.

It is an even better thing to get the program finished, running
correctly, and in such a state that it is easy to alter or maintain.

That last point in the tricolon is a pretty clear argument against
mixing C and C++ in a logical unit; a library, for instance, may be in
C or C++, but it should never be in both simultaneously, because that
will make it considerably harder to maintain.

Charlton
 
B

Bill Reid

Ian Collins said:
All together now: oh yes it does!

It's commonly used where a C++ function has to be passed to a C library
as a callback.

extern "C" specified the linkage type of the function, not its language.
Uh, yeah. It prevents the "name-mangling" of functions compiled
under C++, allowing them to be called from C. It also explicitly
identifies that external functions compiled under C are not "name-mangled"
for proper linking with C++ object files. Once you understand this,
and how to do it, you can call back and forth between C and C++
object files pretty much at will. It is quite obvious that some people
here who are experts on the return value of main() don't understand
this.

Another additional rule is that your C++ functions must not take
or return any data types not found in C. This will quite often require
some special handling of C++ library functions not originally written
to be called from C, but generally doesn't require more than calling
them from a "wrapper" function that takes and returns the allowed
types.

As a response to the original question, it is a "good thing"
to not re-invent libraries just because they may have been
developed in C++ and your C program needs some functionality
in the C++ libraries, or you have a large collection of C libraries
you wrote and now want to use in a C++ program, and other
similar situations. As far as just using stuff from the C standard
libraries in C++ programs, you do have to be careful about
several differences between the two concerning stuff like
enums, type casting, etc.
 
K

Kenny McCormack

Bill Reid said:
object files pretty much at will. It is quite obvious that some people
here who are experts on the return value of main() don't understand
this.

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

CBFalconer

Ian said:
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.
 
K

Kenneth Brody

Richard said:
Ian Collins said:


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

It indirectly allows C to call C++. By compiling with C++, and
declaring a function extern "C", that particular function can call
C++ functions, and can be called from C functions.

At least that has been my experience. I can have legacy C code
call, for example, Microsoft's MFC functions via such a wrapper.

Of course, C++ is irrelevent to comp.lang.c, but C-to-C++ may be
relevent on comp.lang.c++.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
R

Richard Heathfield

Ian Collins said:
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.
 
K

Kenneth Brody

Kenny said:
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.

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. (This is
not just theoretical. I have worked on "real world" platforms where
pointers are returned differently than integers. Specifically, the
Motorola 680x0 series of CPUs have two sets of registers -- one for
"data" and one for "addresses" -- ie: D0, D1, D2 and so on, plus A0,
A1, A2 and so on. Pointers are returned in A0, and ints are
returned in D0. The value of D0 upon return from malloc is
unrelated to the pointer returned in A0, yet the missing prototype
will cause the compiler to assume that D0 contains the return.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
S

SM Ryan

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top