C vs. C++

[Jalapeno]

The simple and clear question is:

,----
| >> What simple program can you program in C that you can not as simply
| >> program in C++?
`----

I don't know if this is the answer to your question but we had an
incorrect results issue that popped up in a C++ compile when a
programmer thought compiling a large C program with a C++ compiler
wouldn't make a difference, iow, he thought since C is a subset of C++
he'd take advantage of the additional error checking of our C++
compiler. The code compiled without errors in both compilers. We can
even show the problem in a very simplified (and contrived) program of
about 20 lines (pardon the trigraphs, this is IBM mainframe C):

#include <stdio.h>
struct A { char c??(2??); };
void odd_results(void) {
int a;
char *b = "abcdefg";
struct B { struct A { char c??(4??); } b; };
struct A x = {0};
/* do stuff using struct B's */
for(a=0;a<sizeof x.c;a++) {
x.c??(a??) = b??(a??);
}
for(a=0;a<sizeof x.c;a++) {
putchar(x.c??(a??));
}
return;
}
int main(void) {
/* call a bunch of functions
using file scope struct A's */
odd_results();
return 0;
}


(Thanks, indirectly, to Chris Torek's post in the clc archives to put
us on the right track to find what was happening)

 

[Tony]

Look Richard, C++ is just syntactic sugar around C.

Proof:

Comeau C++ compiler works by generating C, not assembly.

And the fact that it is one of the best C++ compilers around
proves that you can write in C ANYTHING you can write in C++.

That's misleading or at least incorrect because Comeau generates highly
platform-specific C. Meaning that it takes advantage of compiler-specific
extensions to the C language and OS-specific extensions also I think.

Tony

 

[CBFalconer]

Program in a simple language of course.

FYI Richard the nameless is a troll, and plonked by most. He
appears to insist on replying to messages even though he never will
be read.

 

[CBFalconer]

.... snip ...

Using lcc-win you can still write

int operator = 5;

the "operator" keyword is recognized only in the prefix of a
function definition.

This is the sort of thing that leads to errors. A fundamental
property of good languages is that they do not have peculiar
syntactical interactions. Thus, for example, a word can be read by
the lexer, and immediately classified as one of: identifier, token,
reserved-word, numerical value. C is already suffering from
various character sequences that can be classified differently
depending on syntax. For example, the use of '*'.

 

[CBFalconer]

It may not have an effect on the program (this depends on
definitions) but it certainly has an effect on the programmer.
E.g. it has effects on the compiler (e.g. error detection).
It is simply wrong to state that the by not using features, a
programmer is not affected by the existence of these features.

Another area is simply that the languages are different. Consider
the evaluation of 'A' for example. In C, this is an int. In C++,
this is a char. Such differences can cause very elusive bugs.

 

[Bartc]

Bartc wrote:
...

Even if that code has different behavior in C? Or do you exclude code
that is legal in both C and C++, but with different meanings, from "C-
compatible code"?

I don't know enough about C++ to answer.

And to get back to one of the points, if C++ was used to program using only
C constructs, that's fine, but the array of extra goodies on offer would be
too tempting for most I think, and there would likely be some C++-specific
stuff introduced.

And even if enough discipline was exercised to keep code C-like, there is
still the vast machinery of the C++ compiler to be set in motion for every
compilation. A compiler which has multiply inherited polymorphic template
objects (or whatever) foremost in it's mind might have little priority for
basic stuff.

 

[CBFalconer]

Several Lisp compilers work by generating C, so I suppose Lisp
is just syntactic sugar around C.

To keep it even simpler, I have seen compilers for C, Fortran,
Pascal (and others) that generate assembly language. Thus all
those languages are just syntactic sugar around assembly language.

 

[Lew Pitcher]

To keep it even simpler, I have seen compilers for C, Fortran,
Pascal (and others) that generate assembly language. Thus all
those languages are just syntactic sugar around assembly language.

And, taken to the limit, /all/ compiled computer languages are just
syntactic sugar around machine language. ;-)

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Keith Thompson]

Yes, did you know?

int (*export)(int a,char *name);

is illegal C++.

It is a pity that C++ did not develop positional keywords. In my
extensions to C, I always use positional keywords, i.e. keywords that
would be otherwise a syntax error. Otherwise, they are not recognized
as keywords.

Using lcc-win you can still write

int operator = 5;

the "operator" keyword is recognized only in the prefix of a function
definition.

It would be much easier for all if C++ would follow that convention
but I suppose it is too late now.

I both like and dislike the idea of positional keywords.

In a language that will never change, it's much cleaner IMHO just to
have reserved keywords. Not being able to use "if" or "return" as an
identifier is a small price to pay for the conceptual simplicity of
knowing whether an identifier-like thing is a keyword or not just by
seeing how it's spelled.

The problem is that languages evolve. C99 added several new keywords
that weren't in C90, breaking all existing C90 programs that used
"inline" or "restrict" as ordinary identifiers. On the other hand,
some of the new keywords were added in a form that wouldn't break
existing code, such as _Bool and _Complex -- but of course if those
had been in the language from the beginning, surely "bool" and
"complex" would have been keywords. If I'm programming in C99
(ignoring for the moment the relative lack of support), I shouldn't
have to care when a given keyword was introduced into the language.

Positional keywords require some extra work for the compiler to
recognize whether a given occurrence of, say, "operator" is a keyword
or an identifier. I'm not too concerned about the compiler having to
do extra work, but if the compiler has to work harder to understand
something, the human reader likely will as well.

Ideally, languages should be designed from the start to allow for
future expansion. One approach, I suppose, is not to reserve any
keywords at all. This requires constructing the grammar in such a way
that you can always tell whether a given word is being used as a
keyword for not. This means, for example, that a return statement
can't be allowed to resemble a function call; given:
return (result);
the compiler couldn't tell whether "return" is a function name or the
keyword. (Resolving this based on whether there's a visible function
by that name would cause too many problems.)

Another approach is to use a different syntax for keywords
vs. identifiers. I think Algol did this, though the language itself
didn't define how they were differentiated. You might have a leading
or trailing underscore on each keyword, or require each keyword to
start with an uppercase letter; either way, you'd disallow that form
for identifiers.

Or you can just use a limited set of reserved keywords and make sure
you define the perfect language from the beginning.

 

[Kaz Kylheku]

...

Of course it is not such a serious question, because presumable both
languages are Turing complete.

Turing completeness doesn't say anything about what can be expressed.

Programming languages can differ in their expressive power, or the areas
in which they have expressive power.

The proper form of the question is ``what can you express in C that
you cannot express in C++''.

 

[Keith Thompson]

Turing completeness doesn't say anything about what can be expressed.

Yes, I think it does, assuming that what is "expressed" by a program
is defined by its behavior, and assuming that you restrict "behavior"
to what output is produced for a given input.

Programming languages can differ in their expressive power, or the areas
in which they have expressive power.

They certainly differ in what can be expressed easily.

The proper form of the question is ``what can you express in C that
you cannot express in C++''.

In the sense I've described above, the answer is "nothing". The
answer to the reverse question is also "nothing".

What did you have in mind?

 

[Kaz Kylheku]

Yes, I think it does, assuming that what is "expressed" by a program
is defined by its behavior, and assuming that you restrict "behavior"
to what output is produced for a given input.

I don't agree with this redefinition of "express". There is already the term
"compute" for describing the reduction of input to output. That is not what I
mean by "express"; I'd prefer not to equate the two words at all in any
discussion.

 

[Ian Collins]

There are two "specifiers": class, and typename. Class is somehow
misleading since the parameter can be any type, and not a class.

Which is why typename was added. All languages carry historical baggage.

 

[Ian Collins]

Look Richard, C++ is just syntactic sugar around C.

Proof:

Comeau C++ compiler works by generating C, not assembly.

And the fact that it is one of the best C++ compilers around
proves that you can write in C ANYTHING you can write in C++.

Try implementing RAII directly in C.

 

[Keith Thompson]

I don't agree with this redefinition of "express". There is already
the term "compute" for describing the reduction of input to output.
That is not what I mean by "express"; I'd prefer not to equate the
two words at all in any discussion.

Fair enough. So what *do* you mean by "express"?

Incidentally, the question was "What can you *do* in C that can not be
done in C++?" (emphasis added); I interpret that to refer to behavior,
not necessarily to what can be expressed.

 

[s0suk3]

Look Richard, C++ is just syntactic sugar around C.

You yourself proved how silly this kind of statement is, in a
discussion with Richard Heathfield about C99:

http://groups.google.com/group/comp.lang.c/msg/f704681b1a3f1b83

Richard: "What did C99 give us? Mixed declarations? Sugar. //
comments? More sugar. VLAs? More sugar."

Jacob: "I mean, C is just syntatic sugar for assembly language. Why
not program in assembly then?"

Proof:

Comeau C++ compiler works by generating C, not assembly.

And most C compilers work by generating assembly, not binary.

And the fact that it is one of the best C++ compilers around
proves that you can write in C ANYTHING you can write in C++.

And the fact that most C compilers work by generating assembly proves
that you can write in assembly ANYTHING you can write in C.

See how silly?

Sebastian

 

[Ben Pfaff]

Richard: "What did C99 give us? Mixed declarations? Sugar. //
comments? More sugar. VLAs? More sugar."

Jacob: "I mean, C is just syntatic sugar for assembly language. Why
not program in assembly then?"

I've lost the context on what we're actually arguing here, but
this argument clearly doesn't hold water. C is not syntactic
sugar for any given assembly language, because C is portable
among processors and assembly language is not.

 

[s0suk3]

I've lost the context on what we're actually arguing here, but
this argument clearly doesn't hold water.  C is not syntactic
sugar for any given assembly language, because C is portable
among processors and assembly language is not.

Which just proves how silly these kinds of language comparisons are.

In some senses, C is indeed syntactic sugar for assembly (e.g., the C
code usually maps to assembly). In some other senses, it is not (e.g.,
you can sometimes write C code that is portable to a wider range of
platforms than a particular assembly language could be).

Similar arguments could hold for the C/C++ paradox.

Sebastian

 

[Richard Tobin]

This is the sort of thing that leads to errors.

What sort of errors?

A fundamental
property of good languages is that they do not have peculiar
syntactical interactions. Thus, for example, a word can be read by
the lexer, and immediately classified as one of: identifier, token,
reserved-word, numerical value.

That seems like a property of easy-to-lex languages, not of good ones.

C is already suffering from
various character sequences that can be classified differently
depending on syntax. For example, the use of '*'.

And has that ever led to an error in your code?

-- Richard

 

[Guest]

the discussion probably should have stopped here.
No one seems to be moving from their prepared
positions.

I don't know what you are talking about here to be honest.

I'm guessing you're not being intentionally thick, though
I'm having a hard time understanding how you can fail
to understand this.

You have more ways to do things in C++.

Since
something simple I am assuming we are writing in C and then compiling
withe C++ compiler. Sure there might be some tinkering but was is not
"simple" about it?

The question is "What can you do in C that you can not do as simply in
C++". It is not "can one compile the same code".

no. that's your question. The reason it isn't being answered
is it's the wrong question.

e.g

write a reverse string function

Now, can that be done more simple in C than in legal C++?

in general you can write a solution in a more complex
manner in C++ than in C. I know that's not what you
want to talk about.

We are repeating ourselves so I'll probably give up.

most experienced C programmers know pretty much the whole
language[1]. It's a *lot* harder to learn nearly all
of C++ (I know I've tried).

And that language is pretty much a subset of C++.
yes

The question remains. Keeping in mind that most C will "just compile"
with a C++ compiler too and not take that tangent.

What features of C are "simpler" than the equivalent in C++?

<snip>

in chess a stalemate is declared if the position keeps
repeating.