Is it a good thing that program mix C and C++?
45  1994 
"dolphin" <jd*******@gmail.comwrote in message
news:11*********************@p15g2000hsd.googlegro ups.com...
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.
--
lS
On Mar 27, 9:41 pm, "dolphin" <jdxyw2...@gmail.comwrote:
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.
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
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.
--
Ian Collins.
On Mar 28, 9:41 am, "dolphin" <jdxyw2...@gmail.comwrote:
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
On Mar 28, 11:33 am, CBFalconer <cbfalco...@yahoo.comwrote:
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.
one can call c from c++, and viceversa.
>
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account fromhttp://www.teranews.com
"dolphin" <jd*******@gmail.comwrote:
# Is it a good thing that program mix C and C++?
It is a good thing to get the program finished and running
correctly.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.
Ian Collins said:
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.
No, it doesn't. It makes C functions callable from C++.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote:
Ian Collins said:
>>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.
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.
--
Ian Collins.
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Is it a good thing that program mix C and C++?
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
>>>>"SM" == SM Ryan
>>>><wy*****@tango-sierra-oscar-foxtrot-tango.fake.orgwrites:
SM"dolphin" <jd*******@gmail.comwrote: # Is it a good thing
SMthat program mix C and C++?
SMIt is a good thing to get the program finished and running
SMcorrectly.
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
--
Charlton Wilbur cw*****@chromatico.net
Ian Collins <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
Richard Heathfield wrote:
Ian Collins said:
>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.
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.
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.
---
William Ernest Reid
In article <sD********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:
....
>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.
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Ian Collins said:
Richard Heathfield wrote:
>Ian Collins said:
>>>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.
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote:
>
Ian Collins said:
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.
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:Th*************@gmail.com>
Kenny McCormack wrote:
>
In article <sD********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:
...
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.
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:Th*************@gmail.com>
CBFalconer <cb********@yahoo.comwrote:
# 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.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.
CBFalconer wrote:
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.
It's a two way street.
--
Ian Collins.
Richard Heathfield wrote:
Ian Collins said:
>>Richard Heathfield wrote:
>>>Ian Collins said:
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.
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.
That's almost as daft as asking me to show where ISO/IEC 9899 states
that the sky is blue.
--
Ian Collins.
On Mar 28, 10:30 am, SM Ryan <wyrm...@tango-sierra-oscar-foxtrot-
tango.fake.orgwrote:
CBFalconer <cbfalco...@yahoo.comwrote:
# 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.
Ian Collins said:
Richard Heathfield wrote:
<snip>
>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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote:
Ian Collins said:
>>Richard Heathfield wrote:
<snip>
>>>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.
--
Ian Collins.
Ian Collins said:
There is a world beyond ISO/IEC 9899
Chapter and verse, please. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote:
Ian Collins said:
>>There is a world beyond ISO/IEC 9899
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....
--
Ian Collins.
In article <57*************@mid.individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>>>There is a world beyond ISO/IEC 9899
>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....
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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard Heathfield <rj*@see.sig.invalidwrites:
Ian Collins said:
>Richard Heathfield wrote:
>>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).
--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ian Collins wrote:
CBFalconer wrote:
>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.
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
Ian Collins wrote:
>>CBFalconer wrote:
>>>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.
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.
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.
--
Ian Collins.
On Mar 28, 1:39 pm, "Sheth Raxit" <raxitsheth2...@yahoo.co.inwrote:
On Mar 28, 11:33 am, CBFalconer <cbfalco...@yahoo.comwrote:
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.
one can call c from c++, and viceversa.
i was 'technically' wrong, but i think effect is almost same.
>
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account fromhttp://www.teranews.com- Hide quoted text -
- Show quoted text -
Kenneth Brody <ke******@spamcop.netwrote in message
news:46***************@spamcop.net...
Kenny McCormack wrote:
In article <sD********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:
...
>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.
>
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...
---
William Ernest Reid
CBFalconer <cb********@yahoo.comwrote:
Ian Collins wrote:
CBFalconer wrote:
Ian Collins wrote:
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.
It's a two way street.
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.
--
pa at panix dot com
Bill Reid wrote:
>
.... 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?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
Bill Reid wrote:
... 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?
Nowhere! Which is why I am concerned about the topicality of
this previous post in this thread:
Date: Wed, 28 Mar 2007
From: CBFalconer <cb********@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Is it a good thing that program mix C and C++?
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
---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?
---
William Ernest Reid
In article <Y0*********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:
(poor, misunderstood CBF wrote)
>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 <cb********@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Is it a good thing that program mix C and C++?
dolphin wrote:
>>
Is it a good thing that program mix C and C++?
(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.
"Kenny McCormack" <ga*****@xmission.xmission.comwrote in message
news:eu**********@news.xmission.com...
In article <sD********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:
...
>>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.
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++.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
In article <Rs******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:
....
>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.
On Fri, 30 Mar 2007 23:37:26 +0100, Malcolm McLean wrote:
"Kenny McCormack" <ga*****@xmission.xmission.comwrote in message
news:eu**********@news.xmission.com...
>In article <sD********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote: ...
>>>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.
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 <OTuse new() <OT>?
Martin
--
Martin Golding | He who steals my code steals trash.
DoD #0236 | (Twas mine, tis his, and will be slave to thousands.)
A poor old decrepit Pick programmer. Sympathize at: fo*****@comcast.net Vancouver, WA
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On 31 Mar, 07:29, Richard Heathfield <r...@see.sig.invalidwrote:
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.
And 170 times a day the other 105.25 days. Emphasis on
"at least".
--
Bill Pursell
Kenny McCormack wrote:
[...]
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.
However, there are times when a newbie mentions that the reason
for putting the cast on malloc in the first place was to stop the
compiler from complaining about the int-to-pointer conversion.
While one might argue that the forgotten include won't happen in
"production code", the audience for clc is much wider than those
who write C for a living.
Yes, the cast is "harmless" if you have the proper #include. But,
it appears to be a relatively common newbie error to forget the
necessary #include, and they learned somewhere that you can "shut
up" the compiler by adding the cast, rather than by fixing the
root cause of the problem.
Now, I have an excuse for casting the return at times -- I learned
C in pre-void days, when the cast was necessary. Those days are
long gone, but old habits are hard to break. (Just try typing the
word "print" without a "f" magically appearing after it.)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
Those days are
long gone, but old habits are hard to break. (Just try typing the
word "print" without a "f" magically appearing after it.)
More than once, while writing English text, I've used the word "gets"
and then gone back to put an 'f' at the beginning.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
I try, and I'm just as quick to make a fool of myself as anybody.
Usually I don't make a complete fool of myself, but that happens too.
--Brendan Sechter in comp.lang.c
In article <11*********************@p15g2000hsd.googlegroups. com>,
dolphin <jd*******@gmail.comwrites
>Is it a good thing that program mix C and C++?
If you mean in the same file NO.
If you mean can you call other modules written in C from a C++ program
then that is OK. Many libraries are written in C
However you should not be compelling C in a C++ compiler
C++ is based on C90 and has diverged one way whilst C99 went a
different way.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <11**********************@p15g2000hsd.googlegroups .com>,
user923005 <dc*****@connx.comwrites
>On Mar 27, 9:41 pm, "dolphin" <jdxyw2...@gmail.comwrote:
>Is it a good thing that program mix C and C++?
The C++ language includes the standard C libraries. Un
Not yet it doesn't TR not with standing.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Mar 27, 11:41 pm, "dolphin" <jdxyw2...@gmail.comwrote:
Is it a good thing that program mix C and C++?
You certainly do *not* want to mix C and C++ idioms in the same source
file (e.g., using new to allocate memory and free() to deallocate it),
but you can certainly have different source files written in different
languages; you just have to pay attention to linkage rules and
parameter passing conventions. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: matty |
last post by:
Go away for a few days and you miss it all... A few opinions...
Programming is a craft more than an art (software engineering, not
black magic) and as such, is about writing code that works,...
|
by: toedipper |
last post by:
Hello,
I am designing a table of vehicle types, nothing special, just a list of
unique vehicle types such as truck, lorry, bike, motor bike, plane, tractor
etc etc
For the table design I am...
|
by: Suresh |
last post by:
Hi,
I am new to C and curious to know some basic questions about C.
Why C is good?
In what way its better than any other languages?
If it is no longer a choice of programming language...why...
|
by: Bonj |
last post by:
I was in need of an encryption algorithm to the following requirements:
1) Must be capable of encrypting strings to a byte array, and decyrpting
back again to the same string
2) Must have the same...
|
by: KV |
last post by:
I'm new to OO Design, and I'm fixing to start writing my very first C#
program. Given the complexity of OO programming, I would like to run
something by this group and get general input.
My...
|
by: Someonekicked |
last post by:
I want to save tables of integers to files.
One way to write the cells as fixed size in the file, is to use
reinterpret_cast.
Is that a bad choice, good choice? I remember once before I posted a...
|
by: John Salerno |
last post by:
I know there's a request for a good IDE at least once a week on the ng,
but hopefully this question is a little different. I'm looking for
suggestions for a good cross-platform text editor (which...
|
by: mast2as |
last post by:
I have posted a few messages in the last few days about a project I am
working on which is a quite simple parser. I ended up using the try/
catch structure as a general mechanism to control what's...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
