C program is standard C++ program?

[strutsng]

I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?

In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.

Please advise. thanks!!

[Christian Bau]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:

"Branimir Maksimovic" <bm***@eunet.yu > writes:

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

[...]

Presumably a header intended to be used by both C and C++ compilers
could have

#ifdef __cplusplus
#define restrict
#endif

This can be dangerous. restrict type qualifier has specific meaning to C
compiler,
and does not mean anything to C++ compiler, so C++ calling C function with
such parameter can lead to undefined behavior,
therefore it is better to live that as it is.

C99 6.7.3p7 says:

An object that is accessed through a restrict-qualified pointer
has a special association with that pointer. This association,
defined in 6.7.3.1 below, requires that all accesses to that
object use, directly or indirectly, the value of that particular
pointer. The intended use of the restrict qualifier (like the
register storage class) is to promote optimization, and deleting
all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning
(i.e., observable behavior).

Though I suppose there might be problems if "restrict" is removed from
the caller but not from the implementation of the function.

I assume you mean "if 'restrict' is removed from the function prototype,
but not from the implementation of the function".

If your code had defined behavior when both the prototype and the
implementation used "restrict", then it still has defined behavior when
"restrict" is removed from the prototype.

However, there is the danger that you write code that you _believe_ has
defined behavior because the prototype had no "restrict", but has indeed
undefined behavior because the implementation used "restrict".

[John Carson]

"Michael Wojcik" <mw*****@newsgu y.com> wrote in message
news:dj******** *@news1.newsguy .com

In article <dj***********@ otis.netspace.n et.au>, "John Carson"
<jc************ ****@netspace.n et.au> writes:

"Martin Ambuhl" <ma*****@earthl ink.net> wrote in message
news:F8******** ********@newsre ad3.news.atl.ea rthlink.net

It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++
programs.
"C++ was developed from the C programming language and, with few
exceptions, retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.

If you'd bothered to check, you'd see that this has been introduced
as an argument in this debate countless times (pretty much every time
the question has been raised), and someone has invariably pointed out
that it is in no way a satisfactory argument that C and C++ are not
different languages.

Of course they are two different languages. Who is disputing it?
There are certainly those, including Stroustrop, who feel that C++ is
"mostly" a superset of C (whatever that might mean). And there are
many of us who do not. Appeals to authority in this case carry no
weight with us, unless that authority is ISO.

The question of whether C++ is "mostly" a superset of C turns on two
matters:

1. Knowledge of the specification of the two languages and hence of the
departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.

On 1., I feel on safe grounds in appealing to Stroustrup's authority and any
suggestion that his position is based on an erroneous understanding of the
language specifications is plainly silly.

On 2., it is a matter of judgement and a standards body like ISO is never
going to have anything authoritative to say about it. I believe Stroustrup's
judgement carries a lot of weight. It is plainly not authoritative in a
standards sense, but it is nevertheless at least as worthy of consideration
as any other opinion that one might read in a post to this forum.

--
John Carson

[Mark McIntyre]

On Sat, 22 Oct 2005 18:02:30 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:

Character literals are of type char in C++ and of type int in C, but
I've never seen any programs that depend on this difference other than
ones specifically written to demonstrate it.

I've seen real-world cases where it made a difference. I fail to
recall the exact example, tho I've a feeling it was I/O related
(something to do with reading sizeof 'a' characters?)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Sun, 23 Oct 2005 10:51:15 +1000, in comp.lang.c , "John Carson"
<jc************ ****@netspace.n et.au> wrote:

The question of whether C++ is "mostly" a superset of C turns on two
matters:

1. Knowledge of the specification of the two languages and hence of the
departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.
you missed out:
3) The occurence of commonly-used C code which is illegal in C++.
On 1., I feel on safe grounds in appealing to Stroustrup's authority and any
suggestion that his position is based on an erroneous understanding of the
language specifications is plainly silly.

And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.

But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Mark McIntyre <ma**********@s pamcop.net> writes:
[...]

But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.

(referring to C and C++)

I agree. On the other hand, there are rare real-world circumstances
in which it can make sense to program in the *intersection* of the two
languages. Code written in this sub-language can look very similar to
well-written C code, with the most significant difference being
casting the result of malloc().

P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).

--
Keith Thompson (The_Other_Keit h) 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.

[Simon Biber]

Keith Thompson wrote:

Mark McIntyre <ma**********@s pamcop.net> writes:
[...]

But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.

(referring to C and C++)

I agree. On the other hand, there are rare real-world circumstances
in which it can make sense to program in the *intersection* of the two
languages. Code written in this sub-language can look very similar to
well-written C code, with the most significant difference being
casting the result of malloc().

P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).

There are *many* libraries designed to be used either from C or from
C++. Generally they are written in straight C, and the compiled C object
files of the library are linked together with compiled object files of
the user, which could be in any language.

The only part that has to be compiled by both a C compiler and a C++
compiler is the header file, and C++ provides specific constructs to
allow such a thing:

#ifdef __cplusplus
extern "C" {
#endif

/* ... */

#ifdef __cplusplus
}
#endif

This has no effect on a C compiler, which by convention does not define
the __cplusplus macro, but signals to a C++ compiler that the
identifiers declared within are to be linked with a C object file.

--
Simon.

[John Carson]

"Mark McIntyre" <ma**********@s pamcop.net> wrote in message
news:oa******** *************** *********@4ax.c om

On Sun, 23 Oct 2005 10:51:15 +1000, in comp.lang.c , "John Carson"
<jc************ ****@netspace.n et.au> wrote:

The question of whether C++ is "mostly" a superset of C turns on two
matters:

1. Knowledge of the specification of the two languages and hence of
the departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.
you missed out:
3) The occurence of commonly-used C code which is illegal in C++.

No, it is covered by 1. and 2. If C code is illegal in C++, then that is a
violation of the subset-superset relationship as per 1. How common/important
this is falls under 2.

On 1., I feel on safe grounds in appealing to Stroustrup's authority
and any suggestion that his position is based on an erroneous
understanding of the language specifications is plainly silly.

And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.

I will grant you a) but not b). I think Stroustrup knows every last detail
about what C code is not legal C++ code.
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.

The whole issue of backward compatibility is one of great importance and
heavily influenced the design of C++. And since C continues to be used,
compatibility issues remain of relevance. Largely for this reason, the new
incompatibiliti es introduced by C99 have caused a lot of debate on whether
C++ should change in order to incorporate many of the changes to C.

--
John Carson

[P.J. Plauger]

"Simon Biber" <ne**@ralmin.cc > wrote in message
news:43******** *************** @news.optusnet. com.au...

P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).

There are *many* libraries designed to be used either from C or from C++.
Generally they are written in straight C, and the compiled C object files
of the library are linked together with compiled object files of the user,
which could be in any language.

Right, but in our case we have reason to write C code that also
*compiles* as C++ code. And for that reason, we care about the
largest common subset of the two languages.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[P.J. Plauger]

"John Carson" <jc************ ****@netspace.n et.au> wrote in message
news:dj******** ***@otis.netspa ce.net.au...

But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.

Thanks.
The whole issue of backward compatibility is one of great importance and
heavily influenced the design of C++. And since C continues to be used,
compatibility issues remain of relevance. Largely for this reason, the new
incompatibiliti es introduced by C99 have caused a lot of debate on whether
C++ should change in order to incorporate many of the changes to C.

And C++ is indeed changing, at least in sensible ways. With TR1,
C++ has picked up *all* the C99 library changes. The language
has picked up all the preprocessor changes, and the evolution
subcommittee has triaged the remaining additions to the language.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Mark McIntyre]

On Mon, 24 Oct 2005 20:53:07 +1000, in comp.lang.c , "John Carson"
<jc************ ****@netspace.n et.au> wrote:

"Mark McIntyre" <ma**********@s pamcop.net> wrote in message
news:oa******* *************** **********@4ax. com

And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.

I will grant you a) but not b). I think Stroustrup knows every last detail
about what C code is not legal C++ code.

I sincerely doubt that. There's probably no human alive who knows
*every last detail*, and I bet you a pound that Bjarne would be the
first to say that he's not The One.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----