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!!

[Keith Thompson]

Martin Ambuhl <ma*****@earthl ink.net> writes:

John Carson wrote:

"With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.

This is an example of why one should *not* cite Stroustrup as an
authority on this issue. He is obviously an authority on C++, but the
fact is that well-written C programs tend to be uncompilable as
C++. Best C practice is often illegal in C++. Remember that BS has a
horse in this race.

The obvious exception to Stroustrup's statement is casting the result
of malloc() (and realloc()). A well-written C program is likely to
call malloc() and assign the result, without a cast, to a pointer
object of a type other than void*; this is illegal in C++.

Are there other significant exceptions? Let's limit the discussion to
well-written C90 programs.

For example, C++ has several additional keywords, but most C programs
aren't going to happen to use them as identifiers; they provide a
counterexample to any claim that C is a strict subset of C++, but not
to Stroustrup's statement.

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.

So, did you have anything in mind other than casting malloc() that
would cause a typical well-written C program not to be valid C++?

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

[Keith Thompson]

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

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

[Branimir Maksimovic]

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

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

For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.

Greetings, Bane.

[Chris Torek]

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

Are there other significant exceptions? Let's limit the discussion to
well-written C90 programs. [snippage]So, did you have anything in mind other than casting malloc() that
would cause a typical well-written C program not to be valid C++?

One might argue whether this is "well-written", but I have had
C vs C++ scope issues bite, in real C code that someone attempted
to include part of in a C++ program.

The example I like to use is:

% cat t.c
#include <stdio.h>

struct A { int x[1]; };

int main(void) {
struct B { struct A { int x[1000]; } b; } var;

printf("sizeof( struct A) = %lu\n",
(unsigned long)sizeof(str uct A));
return 0;
}
% ln t.c t.c++
% cc -o t t.c
% ./t
sizeof(struct A) = 4000
% cc -o t t.c++
% ./t
sizeof(struct A) = 4
%

This is not the same as the original example (which was of course
much more complicated), but it does demonstrate that C and C++ are
wildly different languages. :-)

(OK, one might also argue that it is not "typical" either. It is
true that collisions on structure names are relatively rare, and
it is probably even more rare to have them matter in this way.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Martin Ambuhl]

Branimir Maksimovic wrote:

For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.

For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.

[Branimir Maksimovic]

"Martin Ambuhl" <ma*****@earthl ink.net> wrote in message
news:BS******** *********@newsr ead3.news.atl.e arthlink.net...

Branimir Maksimovic wrote:

For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.
For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.

Agreed!

Greetings, Bane.

[Nils Weller]

On 2005-10-22, Keith Thompson <ks***@mib.or g> wrote:

John Carson wrote:

"With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.

[...]
For example, C++ has several additional keywords, but most C programs
aren't going to happen to use them as identifiers; [...]

That reminds me of the Unix functions mktemp()/mkstemp(), which take a
template string argument from which they build a unique file name. Most
Unix manual pages, as well as the POSIX/UNIX standards themselves (which
are ignorant of C++), call the prototypes parameter declaration
``template'' (a C++ keyword):

int mkstemp(char *template);

.... which may be the reason why I've run into problems by calling the
character array I passed to mkstemp() ``template'' in C++ code as well
:-)

``new'' and ``class'' are also identifiers I would expect to see in many
C programs written by people unaware of C++ (or by c.l.c. citizens who
use them deliberately to introduce incompatibiliti es because they
dislike the whole compatibility debate so much), but I agree that it's a
minor problem when porting C programs to C++.

[Tim Prince]

Martin Ambuhl wrote:

Branimir Maksimovic wrote:

For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.

For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.

Several of the more popular implementations of C++ do implement a form
of restrict as an extension, in a different way for each compiler. I
fail to see, though, how this solves the bloat and obfuscation problem.

[Michael Mair]

Keith Thompson wrote:

Michael Mair <Mi**********@i nvalid.invalid> writes:

John Carson wrote:

[...]

The statement that "C++ ... with few exceptions retains C as a
subset" is not a statement of intent but a description of the
relationsh ip between the two languages, albeit one that seems to be
directed at C89. I quote again: "With minor exceptions, C++ is a
superset of C. Most differences stem from C++'s greater emphasis on
type checking. Well-written C programs tend to be C++ programs as
well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibilit y, p. 816.

Hmmm, my C code tends to look quite different from my C++ code.
Things I find quite acceptable in C are not acceptable in C++
where better solutions to address certain problems exist.

Apart from the different semantics of void* and ambiguities w.r.t.
overloaded functions, there are better ways to perform explicit
type conversions in C++ than the good old C-style cast.

Stroustrup's statement is that well-written C programs tend to be C++
programs, not that well-written C programs tend to be *well-written*
C++ programs.

The former statement is basically true apart from the issue of casting
the result of malloc(). The latter is not.

I see. Thanks for the pointer (no pun intended).
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Wojcik]

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.

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.

--
Michael Wojcik mi************@ microfocus.com