C vs. C++

[Richard]

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.

Well Chuck, you got something else wrong. No surprise there then. I think
that you will find that more posters read my posts than yours.

Your contribution to this group is nothing more than hot air and bluster
and for some reason you seem to think yourself qualified to correct
people and tell them who they should respond to. You are not.

 

[Guest]

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

you can write code:
1. that behaves identically on C and C++ implementations
2. that does *not* behave identically on C and C++ implementations

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.

sometimes by accident. A group of programmers was supposed to program
in C
but were using a C++ compiler (I'm not claiming this was a good idea).

Some write BOOL and others bool. BOOL was a macro specified in
a project specific header and hence C code. bool is a C++
language word.

I vaguely remember other C++-isms leaking in.

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.

I used to argue this but I believe C++ compilers are roughly as
quick to compile C code as C compilers (they often share common
back ends)

 

[Guest]

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

ah! the turing tar pit

I can write a Haskell compiler in COBOL therefore...

 

[Lew Pitcher]

ah! the turing tar pit

I can write a Haskell compiler in COBOL therefore...

Don't laugh too hard. Although it might be really big, and a pig to run,
such a compiler /could/ be written. IIRC, there was an experimental OS
entirely written in COBOL, and that's at least as complex as a compiler.

(Having written low-level communications protocol handlers and XML parsers
in COBOL, I have /some/ experience in the complexities and capabilities of
such work. I'd much rather use C for such projects, but sometimes the
language is dictated by shop standards and/or financial constraints (how
much is that CODE/390 C Compiler from IBM?) and such decisions are made
without regard for suitability of purpose. Sigh)

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

 

[Richard Tobin]

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.

It's not a question of what *can* be expressed, but of how naturally
it can be expressed. Multiplication can be "expressed" in a language
with only addition, but not as easily or clearly as in a language with
it built in.

I think it's a mistake to call this "expressive power". The term
suggests something too formal. Just call it "expressiveness".

-- Richard

 

[Bartc]

Don't laugh too hard. Although it might be really big, and a pig to run,
such a compiler /could/ be written. IIRC, there was an experimental OS
entirely written in COBOL, and that's at least as complex as a compiler.

How big a stack of punched cards do you think it might need?

(Cobol does still use punched cards, right?)

 

[Lew Pitcher]

How big a stack of punched cards do you think it might need?

I would guess at least a half-million records

(Cobol does still use punched cards, right?)

No. But COBOL source is still limited to 66 columns of source in 80-column
lines. Line numbers are optional

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

 

[Ben Bacarisse]

It's not a question of what *can* be expressed, but of how naturally
it can be expressed. Multiplication can be "expressed" in a language
with only addition, but not as easily or clearly as in a language with
it built in.

Absolutely, but the question then deteriorates to a rather trivial
feature list. For example, C99 allows one to express the notion of an
anonymous automatic lvalue using compound literals, and C++'s
templates one to express the idea of code parametrised by types. The
(original) question only becomes interesting when you add in the fact
that features have costs. These can be in terms of brain-ache as much
as anything else.

 

[Richard Bos]

There is /nothing/ that can be achieved more elegantly or more
efficiently in C, than it can be achieved in C++. Nothing. If you
think there's something then I'll listen intently.

One single malloc() call.

Richard

 

[John Bode]

So which "simple" program in C can you not compile with C++? And please
don't use specific headers - that is not "simple".

The answer, of course, is "none" -- there is no "simple" C program
that cannot be compiled as C++ (modulo known compatibility issues wrt
keywords, prototypes, etc.) and offer similar performance.

The question basically comes down to this: when is the increased
overhead incurred by the features that make C++ worth using offset by
the convenience? For guys doing hard-core number crunching, the
answer is probably "never"; the complex class is a handy abstraction,
but it's not like you can't code an FFT without it.

Jacob's not wrong in that there are aspects of C++ where the rules are
so complicated that code becomes impossible to understand via simple
inspection; however, it does not follow that C is inherently superior
to C++ by virtue of those issues.

 

[REH]

One single malloc() call.

C:
int* p = malloc(sizeof(int));
*p = 123;

C++:
int* p = new int(123);

REH

 

[CBFalconer]

.... snip ...


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

Not recently.

 

[CBFalconer]

([email protected]) wrote:
.... snip ...


Don't laugh too hard. Although it might be really big, and a pig
to run, such a compiler /could/ be written. IIRC, there was an
experimental OS entirely written in COBOL, and that's at least
as complex as a compiler.

Oh yes. I have run into such things. They sit there and chew up
hours of cpu time, and eventually evolve something (assuming no
errors). Useful for the ugly machines that only support COBOL.

 

[jameskuyper]

C:
int* p = malloc(sizeof(int));
*p = 123;

C++:
int* p = new int(123);

That might result in call to malloc(), but there's no guarantee of
that, and it is certainly not itself a call to malloc().

The correct C++ equivalent is:

int *p = (int*)malloc(sizeof(int));

There are 6 extra characters there, and in C++ they're mandatory,
while they are bad programming practice in C. That's how C++ makes
this more complicated. In the general case, it's often a lot more than
6 extra characters.

 

[REH]

That might result in call to malloc(), but there's no guarantee of
that, and it is certainly not itself a call to malloc().

The correct C++ equivalent is:

int *p  = (int*)malloc(sizeof(int));

There are 6 extra characters there, and in C++ they're mandatory,
while they are bad programming practice in C. That's how C++ makes
this more complicated. In the general case, it's often a lot more than
6 extra characters.

I know what he was looking for, but you can't argue elegance, and then
restrict what language features I am allowed to use. Either way, you
are wrong. The language DOES allow me to guarantee that new calls
malloc, if I want it to. Pedantic: You are also wrong I need a cast to
use malloc in C++. You can do it without a cast, but would require
more than 6 extra characters.

REH

 

[Ian Collins]

That might result in call to malloc(), but there's no guarantee of
that, and it is certainly not itself a call to malloc().

The correct C++ equivalent is:

int *p = (int*)malloc(sizeof(int));

There are 6 extra characters there, and in C++ they're mandatory,
while they are bad programming practice in C.

In C++, using malloc is considered bad practice in the general case.
It's certainly bad practice for a single int. So we come back to

int* p = new int(123);

rather than

int* p = malloc(sizeof(int));
*p = 123;

Elegance is in the eye of the beholder.

That's how C++ makes
this more complicated. In the general case, it's often a lot more than
6 extra characters.

new is shorter than malloc and there isn't any need to bother with
sizeof. You never see debates over how to use new on a C++ group like
you see here for malloc.

 

[Ben Pfaff]

There is /nothing/ that can be achieved more elegantly or more
efficiently in C, than it can be achieved in C++. Nothing. If you
think there's something then I'll listen intently.

The following is valid in C but not in C++:
char data[8] = "abcdefgh";

If you change the array size to 9 bytes, then it is valid in C
and in C++, but wastes 1 byte. Therefore, it is more efficient
to define such an array in C than in C++. One could use an
alternate form of initializer, e.g. {'a', 'b', 'c', 'd', 'e',
'f', 'g', 'h'}, in C++, but that's less elegant than using a
string literal.

[...array versus std::vector...]

Regardless of how ingrained and how prevalent this C++ culture is, it
doesn't have any effect on the language itself.

If you view C++ as a set of potentially useful extensions to C,
then sure in most cases you can write code that is at least as
good, in a variety of ways, as equivalent C code. But that is
not the way that C++ gurus promote C++, and in fact many of the
C++ techniques that such gurus push seem to me much less elegant
than the equivalent C techniques.

 

[Ian Collins]

If you view C++ as a set of potentially useful extensions to C,
then sure in most cases you can write code that is at least as
good, in a variety of ways, as equivalent C code. But that is
not the way that C++ gurus promote C++, and in fact many of the
C++ techniques that such gurus push seem to me much less elegant
than the equivalent C techniques.

It's not what the so called gurus say that matters, it's how real world
programmers used the language.

I've come across a lot of C++ code that's little more than C with a few
C++ features (simple inheritance and encapsulation are common).

 

[Kaz Kylheku]

My own personal preference:

int &i = *new int(123);

And then when I'm done with it:

delete &i;

Because, remember, kids, C++ references are not pointers and
are a lot safer!

 

[Guest]

I know what he was looking for, but you can't argue elegance, and then
restrict what language features I am allowed to use. Either way, you
are wrong. The language DOES allow me to guarantee that new calls
malloc, if I want it to.

err... how do you do that? Define your own operator new?

Pedantic: You are also wrong I need a cast to
use malloc in C++. You can do it without a cast, but would require
more than 6 extra characters.

I bet it isn't simple either...