Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C program is standard C++ program?

Reply
Thread Tools

C program is standard C++ program?

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-22-2005
Martin Ambuhl <(E-Mail Removed)> 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_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-22-2005
"Branimir Maksimovic" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...

[...]
>> 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_Keith) (E-Mail Removed) <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.
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      10-22-2005
In article <(E-Mail Removed)>
Keith Thompson <(E-Mail Removed)> 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(struct 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 (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Branimir Maksimovic
Guest
Posts: n/a
 
      10-22-2005

"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Branimir Maksimovic" <(E-Mail Removed)> writes:
>> "Keith Thompson" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...

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


 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      10-22-2005
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.

 
Reply With Quote
 
Branimir Maksimovic
Guest
Posts: n/a
 
      10-22-2005

"Martin Ambuhl" <(E-Mail Removed)> wrote in message
news:BSw6f.19765$(E-Mail Removed) ink.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.

>



 
Reply With Quote
 
Nils Weller
Guest
Posts: n/a
 
      10-22-2005
On 2005-10-22, Keith Thompson <(E-Mail Removed)> 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 incompatibilities because they
dislike the whole compatibility debate so much), but I agree that it's a
minor problem when porting C programs to C++.

 
Reply With Quote
 
Tim Prince
Guest
Posts: n/a
 
      10-22-2005
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.
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      10-22-2005
Keith Thompson wrote:
> Michael Mair <(E-Mail Removed)> 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
>>>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.


I see. Thanks for the pointer (no pun intended).


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      10-22-2005

In article <djd5ob$2tqj$(E-Mail Removed)>, "John Carson" <(E-Mail Removed)> writes:
> "Martin Ambuhl" <(E-Mail Removed)> wrote in message
> news:F8o6f.19590$(E-Mail Removed) nk.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 (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
standard libraries don't behave like standard 'libraries' Sriram Srinivasan Python 13 11-12-2009 06:05 PM
What are the standard network functions provided in standard C? disappearedng@gmail.com C Programming 5 06-10-2008 08:57 PM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
C program is standard C++ program? strutsng@gmail.com C++ 50 10-30-2005 10:28 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM



Advertisments