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

 

[Jonathan Mcdougall]

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

No.

void template()
{
}

int main()
{
template();
}

is a valid C, but invalid C++. Check your favorite textbook (you do
have one, don't you?) or google for more informations on C and C++
incompatibilities.

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

It depends on what you call a "C++ library".

extern "C"
{
void f();
}

Is this a "C++ library"? If yes, then a C program can use some C++
libraries. Your question is too vague.


Jonathan

 

[Marcus Kwok]

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

In most cases, yes, but there are a few cases where this is not true.
For example, if a C program declares identifiers that are now C++
keywords but that are not C keywords. TC++PL has a section on this
topic.

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

True.

 

[Marcus Kwok]

True.

After reading Jonathan's post, I will amend this to mean the standard
C++ libraries, e.g., the STL.

 

[Heinz Ozwirk]

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

No. Not every C program is also a valid C++ program. "new", "class" or
"template" to name only a few, are valid identifiers in C, but they are
reserved words in C++. So any C program using one of these identifiers is
not a valid C++ program. Also

void foo();
int main() { foo(1); }

is legal in C, but not in C++

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

Just that you can use C libraries in C++ does not imply that C is a subset
of C++. You can also use Pascal or Fortran libraries in C++, but that is no
reason to think that every Pascal or Fortran program is also a C++ program.

Heinz

 

[Alex Vinokur]

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

[snip]

int main()
{
char a[3] = "foo";
return 0;
}

It is legal in C, but not in C++.

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

 

[Emmanuel Delahaye]

(e-mail address removed) a écrit :

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

No, it's not

http://david.tribble.com/text/cdiffs.htm

Unfortunately, this link seems to be down at the moment.
Maybe, more information here :

david at tribble dot com

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

Correct.

 

[Martin Ambuhl]

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

It is a grossly erroneous statement. C and C++ are different languages.
There are countless C programs that are not C++ programs.

 

[John Carson]

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.

 

[Michael Mair]

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

This may have been the intent; however, Martin's statement still is
true as C++ semantics differ from C89 in many points.
C99 introduced enough additional non-trivial differences which cannot
be easily overcome. The C standard does not make any claim w.r.t. C++
compatibility, even though there may be a rationale saying exactly
that. I do not own the C++ standard, so I cannot say anything from
this point of view.

Cheers
Michael

 

[John Carson]

This may have been the intent; however, Martin's statement still is
true as C++ semantics differ from C89 in many points.

The statement that "C++ ... with few exceptions retains C as a subset" is
not a statement of intent but a description of the relationship 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,
Compatibility, p. 816.

C99 introduced enough additional non-trivial differences which cannot
be easily overcome.

That does indeed add to the incompatibility, though there are efforts
underway to bring the two languages closer together, particularly by adding
C99 stuff to C++.

The C standard does not make any claim w.r.t. C++
compatibility, even though there may be a rationale saying exactly
that. I do not own the C++ standard, so I cannot say anything from
this point of view.

Section 1.1/2 of the C++ standard:

"C++ is a general purpose programming language based on the C programming
language as described in ISO/IEC 9899:1990 Programming languages - C (1.2).
In addition to the facilities provided by C, C ++ provides additional data
types, classes, templates, exceptions, namespaces, inline functions,
operator overloading, function name overloading, references, free store
management operators, and additional library facilities."

Annex C (appropriately enough) of the C++ standard deals with the
relationship between C and C++, noting the areas of incompatibility.

 

[Rolf Magnus]

"Well-written C programs tend to be C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.

I tend to disagree. In C, dynamic memory is usually allocated with malloc or
other functions that return a pointer to void. That pointer gets converted
implicitly into the target type in C, and a cast should be avoided in a
"well-written C program". However, in C++, it doesn't compile without a
cast. Dynamic memory is something that is used quite often, so I'd say that
most well-written C programs are not C++ programs and would need lots of
changes (in all places where dynamic memory is allocated).

 

[John Carson]

I tend to disagree. In C, dynamic memory is usually allocated with
malloc or other functions that return a pointer to void. That pointer
gets converted implicitly into the target type in C, and a cast
should be avoided in a "well-written C program". However, in C++, it
doesn't compile without a cast. Dynamic memory is something that is
used quite often, so I'd say that most well-written C programs are
not C++ programs and would need lots of changes (in all places where
dynamic memory is allocated).

Your point is covered in the preceding sentence: "Most differences stem from
C++'s greater emphasis on type checking." But I guess that this preceding
sentence somewhat gives the lie to the one that follows, so strictly
speaking you are probably right that "most well-written C programs are not
C++ programs".

I am more sceptical about your claim that they would need "lots of changes".
Well written C programs will hide most of the malloc calls inside
initialization functions --- manual equivalents of constructors --- and the
number of these shouldn't be very large.

 

[Michael Mair]

The statement that "C++ ... with few exceptions retains C as a subset" is
not a statement of intent but a description of the relationship 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,
Compatibility, 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.

That does indeed add to the incompatibility, though there are efforts
underway to bring the two languages closer together, particularly by adding
C99 stuff to C++.

Yes, AFAIR there were a couple of good articles by B.Stroustrup in CUJ
about the areas where this is easily possible and where in his opinion,
either C++ or C should change semantics. They may still be available
online.

Section 1.1/2 of the C++ standard:

"C++ is a general purpose programming language based on the C programming
language as described in ISO/IEC 9899:1990 Programming languages - C (1.2).
In addition to the facilities provided by C, C ++ provides additional data
types, classes, templates, exceptions, namespaces, inline functions,
operator overloading, function name overloading, references, free store
management operators, and additional library facilities."

Annex C (appropriately enough) of the C++ standard deals with the
relationship between C and C++, noting the areas of incompatibility.

Thank you for the information


Cheers
Michael

 

[Branimir Maksimovic]

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.

No we can't

extern "C"{
void strcpy(char* restrict , const char* restrict);
}

Standard C++ compiler should spit error.
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.

However, we cannot

use C++ libraries inside C program.

Yes we can
extern "C" void myfunc(int){ MyClass o; } // defines C function
// that can be called from C

Greetings, Bane.

 

[Branimir Maksimovic]

No we can't

extern "C"{
void strcpy(char* restrict , const char* restrict);

void strcpy(char* restrict to, const char* restrict from);

}

Standard C++ compiler should spit error.

Worse, if there are no variables it can interpret "restrict" as parameter
name
instead of type qualifier

 

[Keith Thompson]

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
relationship 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,
Compatibility, 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.

 

[Keith Thompson]

No we can't

extern "C"{
void strcpy(char* restrict , const char* restrict);
}

Standard C++ compiler should spit error.
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.

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

#ifdef __cplusplus
#define restrict
#endif

 

[Martin Ambuhl]

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

 

[Branimir Maksimovic]

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.

Greetings, Bane.