Why do people still use C instead of C++ ?

[Laurent Deniau]

I had wanted to take a stab at it, but:

1. COS is not actually available on SourceForce except through CVS.
Not very convenient.

Right (sorry for this), I am working on the tarball for next week. I
still need to improve install/uninstall targets of makefiles and some
minor things.

2. The COS Makefiles do not build. It appears you used something like
autoconf but did not actually include a configure script in CVS.

It's only makefiles, but it requires gmake (tested with gmake 3.81).
There is no configure or so to run.

The
compilation instructions in your README are incorrect. After looking
for the source of the problem and seeing the number of environment
variables that were not defined (e.g. everything checked for by the
'prologue' include file), I gave up.

COS is actually tested on MacOSX and Linux since I don't have access
to other architectures. Makefiles are not portable to Windows unless
you install cygwin or equivalent. The config file are not yet done for
it. Maybe you tried on a yet unsupported architecture? The structure
of the makefile is similar to the makefiles of POCO++.

3. While it's certainly an interesting project, you seem to have
reinvented a serious wheel. If a developer used COS in an application,
then more likely there were better tools for that developer's job than
C in the first place.

Like? AFAIK, the COS features are unique in a single "language". The
closest would be a mix between Objective-C, CLOS and Dylan.

Why did you fail to do it in C++? What specific problems are you
referring to?

- COS needs a C99 preprocessor. Maybe the next release of C++ will get
the equivalent.

- the object model is completely different from the C++ one and it's
rather difficult to combine the two.

- multi-method would have to deal with lookup, overloading and
templates. This is far beyond the capabilities of my macros.

Issues with... type checking or something?

no, it's not an issue. C and C++ are close enough on that point. In
particular, all COS objects are structures, which make the objects
system strongly statically typed in both languages except that C++
would provide subtyping while C doesn't.

It's fairly
straightforward to compile C with a C++ compiler; most of the changes
involve adding explicit casts and changing names that are now C++
keywords (e.g. "class").


Most issues are described here:http://docs.hp.com/en/92501-90029/ch01s03.html
, search the page for "changing your C programs to C++".

This paper is about C89. Nevertheless, I do not use C++ keyword (eg.
self and not this for my receivers).

C does not have support for multi-methods, nor does C++, in both
languages you have to emulate them some other way. I can certainly
imagine various schemes for implementing them in C++; they are
probably similar to what you did in C.

Probably not. In C++ you must stay compliant with the existing. Issues
are those already mentioned, but also management of multi and virtual
inheritance, portability of "generic" pointers to (member) functions
and template functions, support for meta-classes with the unicity of
the ids (not ensured by C++), etc...

What is it about C++ that you
found to be a barrier to implementing these? There are plenty of ways
to do runtime type checking in C++...

Yes. But the "normal way" in C++ would be double (or more) dispatch on
top of the C++ object model. This is not easy to automatize nor
efficient (this is the way multijava works). The dispatcher of COS is
as fast as C++ virtual member functions on Linux 64bits with gcc4.

Same deal with messaging systems, which are just as trivial to
implement in C++ as they are in C.

Not exactly. Dispatch is not the all story and it's far beyond this
thread to explain the all story. In order to get an idea, you can
still read the slides

http://cos.cvs.sourceforge.net/viewvc/cos/CosBase/share/doc/cos/slides-cos.pdf.gz

or the paper (longer, obsolete, but gives an idea)

http://cos.cvs.sourceforge.net/viewvc/cos/CosBase/share/doc/cos/cos-overview.pdf.gz

Jason

P.S. Just to set the tone, I don't have a problem with C at all, and
still use it for some applications.

Neither me ;-) I am just looking for the right tool for my need
(numerical computation & simulation).

Mostly I'm wondering if you've
actually been having issues with C++, or if the issues are because
your implementation attempts failed for other reasons.

This is more related to C++. In fact you can also have a look at the
second half of the presentation once you have read the COS
presentation. This is a kind of "motivation for COS".

http://cos.cvs.sourceforge.net/viewvc/cos/CosBase/share/doc/cos/slides-design.pdf.gz

You can also google about "strong typing vs strong checking" to get an
idea why I changed my mind and introduce more dynamics in my code.

a+, ld.

 

[Matthias Buelow]

Shouldn't C++ have replaced C? even when developing an OS kernel or
such sensitive software.

Maybe it's because "OS kernel or such sensitive software" is often the
domain of hackers or research programmers, who probably don't have much
love left for something... bulbous... like C++. For business
programming, where managing a team of average, exchangable programmers
is paramount, the situation might be slightly different.

 

[Grizlyk]

why does any programmer on earth still use/learn/
teach C instead of C++?

But use or learn?

About learn.
People do not know strictly niether C no C++, and are not going to do
it, so people learn something mixed that looks more as subset of C++.
They learn the subset of C++ because of existing functional
(algorithmic) paradigm of programming - C, pascal and C++ support the
paradigm. People do not need C++ or C, they need only implementation
of the paradigm.

This is wrong idea, that anyone can learn object-oriented paradigm
without or befor funcional one.

About use.
What do you mean? People call functions, is it C? Or you are about
libraries? Again, anyone try to force others with concrete library?

Any good thing do no require any vague adverticement. If people select
C library, that means that profit from C++ libraries, that do the
same, does not visible. Probably C++ implementation worse, probably
there is no online help dictionary for their IDE to recollect
interfaces of C++ interfaces, probably something else.

Shouldn't C++ have replaced C even when developing an OS kernel or
such sensitive software?

C++ has some "elements of OO paradigm" only and must be redesigned to
support OO properties in effective manner. As alternative way, you can
use right now the considered above subset of C++ for functional
projets.

 

[Greg Herlihy]

Hello.

AFAIKnew, people used to choose C over C++ as a programming language
for their projects because it posses better performance and execution
speed, but after I read this article <a herf="http://unthought.net/c++/
c_vs_c++.htmle">(C versus C++)</a> I noticed that C++ beats C in
benchmarking so, why does any programmer on earth still use/learn/
teach C instead of C++?

Shouldn't C++ have replaced C? even when developing an OS kernel or
such sensitive software.

The entire premise of the question is, of course, completely false.
There is no such thing as a programmers who writes code in "C". There
do exist, however, a sizable number of C++ programmers who do decide -
for a variety of reasons (including inertia, smug self-righteousness
and -in most cases- simple mental illness) to use only a very limited
subset of the C++ programming language when they program. (For
example, many of these programmers will eschew C++ templates in favor
of preprocessor macros. And yes, despite the wildly implausibility of
this claim, this behavior has been documented in the field). In fact,
many of these afflicted programmers have become so delusional that
they no longer realize that they are programming in C++. Many believe
instead that they are programming in some other language (often, a
made-up programming language they call "C"). And, yes, there is ample
evidence to support this outlandish-sounding claim.

Of course the harm done by these programmers (who refuse to use the
full suite of C++ language) - is enormous. Think of all extra delays,
added bugs, and nightmarish maintenance scenarios that their refusal
directly cause.

Nevertheless, despite the clear incentive to fix this crisis, efforts
to reach this group of afflicted programmers and to provide them with
the help they need, have, by and large, proved unsuccessful. In many
cases, these programmers have had years to construct their defenses.
Often the programmer has entrenched themselves so thoroughly in the
software-writing process of their organization, that any thought of
extrication is simply not feasible..

Nevertheless, there are few small steps that we, as individual, right-
minded C++ programmers, can do to fight this huge problem. Here are a
few practices that every true C++ programmer should adopt immediately
in their day-to-day lives:

* Always correct any mention or reference to a "C" programming
language - immediately and forthrightly. Make it clear to your
audience that the correct term is: "the C++ programming language (or
some subset thereof)" Be sure to use the corrected phrase in its
entirety - do not abbreviate the correction in any way. Remember that
allowing any reference to a "C" programming language to go
unchallenged, only serves to feed the collective delusion.

* Whenever "C" code is discovered in a program, immediately rewrite
the infected program immediately and completely (using proper C++).
Leaving the malignant code as is, greatly increases the risk of
contagion.

* Train yourself to recognize the telltale signs of the C programming
psychosis in other programmers. For example, someone who uses /* */
instead of // to set off comments, or who religiously makes sure that
all declarations precede statements in the same scope, or who use an
overabundant number of preprocessor macros and #defines - is certainly
a peerson who warrants closer scrutiny. Remember, even noticing
something minor can nonetheless prove to be the decisive tip-off that
a fellow C++ programmer desperately needs your help. A note of
caution: once you have identified a sick C++ programmer, do not
confront the individual yourself. Instead, seek out the assistance of
a trained professional, competent in conducting the intervention (and
internment) that will be needed.

So. there you have it. The near term prognosis for ending this crisis
does remain bleak. Our best hope is that we each, on our own, fight
this problem locally, in our day-to-day lives. The hope is that - by
dint of our collective efforts - we will eventually turn the tide and
end this terrible scourge.

Greg

 

[vib.cpp]

Hello.

AFAIKnew, people used to choose C over C++ as a programming language
for their projects because it posses better performance and execution
speed, but after I read this article <a herf="http://unthought.net/c++/
c_vs_c++.htmle">(C versus C++)</a> I noticed that C++ beats C in
benchmarking so, why does any programmer on earth still use/learn/
teach C instead of C++?

Shouldn't C++ have replaced C? even when developing an OS kernel or
such sensitive software.

i am now learning c++ for several months,with a book said i do not
have a pre-knowledge of c language,but when i know something about
cpp,a stronger feeling is that i must go and find some c language book
to solid my foundation now.I think some fundamental knowledge of
programming is easier to get familiar with from c ,

 

[coal]

The entire premise of the question is, of course, completely false.
There is no such thing as a programmers who writes code in "C". There
do exist, however, a sizable number of C++ programmers who do decide -
for a variety of reasons (including inertia, smug self-righteousness
and -in most cases- simple mental illness) to use only a very limited
subset of the C++ programming language when they program. (For
example, many of these programmers will eschew C++ templates in favor
of preprocessor macros. And yes, despite the wildly implausibility of
this claim, this behavior has been documented in the field). In fact,
many of these afflicted programmers have become so delusional that
they no longer realize that they are programming in C++. Many believe
instead that they are programming in some other language (often, a
made-up programming language they call "C"). And, yes, there is ample
evidence to support this outlandish-sounding claim.

Of course the harm done by these programmers (who refuse to use the
full suite of C++ language) - is enormous. Think of all extra delays,
added bugs, and nightmarish maintenance scenarios that their refusal
directly cause.

Nevertheless, despite the clear incentive to fix this crisis, efforts
to reach this group of afflicted programmers and to provide them with
the help they need, have, by and large, proved unsuccessful. In many
cases, these programmers have had years to construct their defenses.
Often the programmer has entrenched themselves so thoroughly in the
software-writing process of their organization, that any thought of
extrication is simply not feasible..

Nevertheless, there are few small steps that we, as individual, right-
minded C++ programmers, can do to fight this huge problem. Here are a
few practices that every true C++ programmer should adopt immediately
in their day-to-day lives:

* Always correct any mention or reference to a "C" programming
language - immediately and forthrightly. Make it clear to your
audience that the correct term is: "the C++ programming language (or
some subset thereof)" Be sure to use the corrected phrase in its
entirety - do not abbreviate the correction in any way. Remember that
allowing any reference to a "C" programming language to go
unchallenged, only serves to feed the collective delusion.

* Whenever "C" code is discovered in a program, immediately rewrite
the infected program immediately and completely (using proper C++).
Leaving the malignant code as is, greatly increases the risk of
contagion.

Previously I asked, "if not now, when?" regarding gcc/g++
development. http://preview.tinyurl.com/7qeokl

It would be great to hear of an effort to rework gcc as a C++
program. I think it would shed at least 30% of it's current
size if that were to happen. Unfortunately, people keep pasting
more on to large "C" programs and the programs turn into monsters.
I agree with the use of the word crisis here. We need to bite
the bullet and rewrite gcc.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[pgadmin]

I just remembered something about the 1st version of C++.
Strousrup (sic) came to Cambridge, Mass. to implement the
fist version of C++. There was no C++ then. We were working
basically a couple of offices away, and once I asked him:

Why C++ is implemented as preprocessor and not a compiler
proper. He blabbered something that could not possibly
make sense because basically there is not excuse to implement
C++ as a preprocessor to C.

Btw, do you know how they made C++ objects?

Well, they patched the executable produced by C
after linking stage.

How do you like THAT fer breakfast?

:--}

 

[James Kanze]

(e-mail address removed) wrote:

This is, of course, false. There is still a C language, there
are C compilers, and some people are still using them.

I just remembered something about the 1st version of C++.
Strousrup (sic) came to Cambridge, Mass. to implement the fist
version of C++. There was no C++ then. We were working
basically a couple of offices away, and once I asked him:

Why C++ is implemented as preprocessor and not a compiler
proper. He blabbered something that could not possibly make
sense because basically there is not excuse to implement C++
as a preprocessor to C.

Well, very soon there was a C++ compiler proper.

Except that C++ was invented by a guy named Stroustrup, not
Strousrup, at Bell labs in New Jersey. (I don't think
Stroustrup ever worked or studied at Cambridge, Mass. His PhD is
from Cambridge University, in Cambridge, UK.)

And of course, C++ was never a "preprocessor" for C. Like many
languages, the early (and some not so early) compilers used C as
an intermedite, machine independent, intermediate language,
between the front-end and the back-end.

But what if you write device driver or kernel code?
The entire Linux kernel, the last time I looked at the sources,
is written in C.

That probably explains why it is so unreliable. (Or at least
why it took so long to acquire even a semblance of reliability.)

At the kernel level, there is a difference between C and C++.

At all levels, there's a difference. They're two different
languages.

And that difference is performance. At the kernel level, each
indirection is a memory reference, which is much slower than
register access.

The penalty in performance is probably around 50%, AT LEAST,
compared to pure C.

That's bullshit, of course. All of the compilers I've seen
generate exactly the same code for C and for C++. (Potentially,
C++ could be faster, because it provides more information to the
compiler. For various reasons, however, this isn't the case,
and I don't really expect it to ever be the case.)

Modern OS's are written in C++. Modern OS's are rare, though;
most OS's have been around for a long time, and have just grown.

 

[s0suk3]

At the kernel level, there is a difference between C and C++.

Although I'm not familiar with kernel development, I do have heard
about a few such differences (e.g., things having to do with the ABI).
However, what you point out:

And that difference is performance.

is NOT one of the differences. Every feature of C++ that is also
available in C has the same behavior and semantics in C++ as it does
in C.

Although there might be some variations in the resulting machine code
when C/C++ code is compiled in C mode and when it's compiled in C++
mode, the performance doesn't usually vary. For example, name mangling
is usually done differently for C++ code than for C code. Of course,
the resulting mangled names have nothing to with code speed.

(Read James Kanze's post to hear why C++ mode could in fact yield
faster code.)

At the kernel level,
each indirection is a memory reference, which is much slower
than register access.

You can reference a memory location and access a register in both C
and C++, in the same ways.

The penalty in performance is probably around 50%, AT LEAST,
compared to pure C.

Unsupported claim. Repeat after me: Every feature of C++ that is also
available in C has the same behavior and semantics in C++ as it does
in C.

Sebastian

 

[Grizlyk]

At the kernel level, there is a difference between C and C++.

For example, protability. But, in order to speak about language we
must select level of discussion
- standard C++,
- real compilers and environment
- etc.

If you take "ordinary C++ environment" and "ordinary C environment",
that you will easy find profits for "pure C" for the kind of programs.
But if you will speak about "what C++ could do", then "C++" would be
better.

And that difference is performance. At the kernel level,
each indirection is a memory reference, which is much slower
than register access.

Yes, C++ allows users to write code with bad performance. For example,
well known string operation. Some users copy strings by value in free
manner and easy lose performance. You must use abstractions of C++
with care.

As i have said, now the best way to use C++ is some ADT+templates
+patterns under C-stile design. You will get profits without lost of
any performance.

===
grizlyk

 

[tonytech08]

I just remembered something about the 1st version of C++.
Strousrup (sic) came to Cambridge, Mass. to implement the
fist version of C++. There was no C++ then. We were working
basically a couple of offices away, and once I asked him:

Why C++ is implemented as preprocessor and not a compiler
proper. He blabbered something that could not possibly
make sense because basically there is not excuse to implement
C++ as a preprocessor to C.

Maybe not any "excuse" but a good reason to do so at least as a mental
exercise: not doing so just keeps building up more and more
monstrousness in already too complex compiler machinery. Chasing that
100% "solution" rather than the 80% one, ... well you know that
factoid.

 

[tonytech08]

On Jan 4, 8:46 am, (e-mail address removed) (pgadmin) wrote:

Modern OS's are written in C++.  Modern OS's are rare, though;
most OS's have been around for a long time, and have just grown.

"Operating System" is VERY subjective (vague) terminology. Were you
thinking Solaris? Windows? A particular kernel? A kernel-less "OS"?
Apparently ALL OS's are or were "modern". The new Xinu? Neutrino?
Contiki? By "modern", did you mean "in commercial production" (in
which case it sounds like an oxymoron)?

 

[tonytech08]

You can reference a memory location and access a register in both C
and C++, in the same ways.

Which of course, and aside, is pretty much THE main characteristic
that defines a language that is "close to the hardware".

(Note to self: relevance to current topics).

 

[James Kanze]

"Operating System" is VERY subjective (vague) terminology.

Not subjective, but not really very precise, no.

Were you thinking Solaris? Windows? A particular kernel? A
kernel-less "OS"?

Yes. I was using it in the most general sense.

Apparently ALL OS's are or were "modern".

Are or WERE, yes. Solaris was "modern" in the early 1990's.
Today, of course, it's just there. From what little I know, all
of the current Windows releases have a Windows NT code base at
heart; that goes back to over ten years as well.

The fact is that there hasn't been much real evolution in OS
technology for a while, and the older systems serve present
needs quite well. So there's been no reason to rewrite them.
(In the case of Solaris, Sun did sell a real-time OS, Chorus,
for a while. They've discontinued it; presumable all of the
functionality has been moved into Solaris. Since Chorus was
written entirely in C++, it's quite likely that parts of Solaris
are in C++ as well. Note that Chorus started back in the 1980s;
even back then, the most advanced OSs were being written in C++.)

The new Xinu? Neutrino? Contiki? By "modern", did you mean
"in commercial production" (in which case it sounds like an
oxymoron)?

By "modern", I meant "developed recently". I should have been
more precise---Windows and Solaris are both "modern" in the
commercial sense, even though both use a fairly old code base at
their heart.

 

[arnuld]

In terms of learning C++, doesn't seem like a productive thread..

 

[Ian Collins]

At the kernel level, there is a difference between C and C++.

And that difference is performance. At the kernel level,
each indirection is a memory reference, which is much slower
than register access.

The penalty in performance is probably around 50%, AT LEAST,
compared to pure C.

Care to prove that?

 

[Ian Collins]

That's bullshit, of course. All of the compilers I've seen
generate exactly the same code for C and for C++. (Potentially,
C++ could be faster, because it provides more information to the
compiler. For various reasons, however, this isn't the case,
and I don't really expect it to ever be the case.)

One case where C++ will generate faster optimised code is generic
algorithms implemented with templates. Sorting is one case, where C has
to use void* and a comparison function, removing any possibility of
inlining (see qsort).

 

[Chris M. Thomasson]

<5740713c-c2f3-427e-aa5a-65864477b5de@z28g2000prd.googlegroups.com>, [...]
But what if you write device driver or kernel code?
The entire Linux kernel, the last time I looked at the sources,
is written in C.

At the kernel level, there is a difference between C and C++.

And that difference is performance. At the kernel level,
each indirection is a memory reference, which is much slower
than register access.

The penalty in performance is probably around 50%, AT LEAST,
compared to pure C.
:^/




C++ is a toy kind of thing.

You can easily use C++ at the kernel level by making extensive use of POD's.
You don't have utilize every aspect of C++, just the parts you need.

 

[James Kanze]

One case where C++ will generate faster optimised code is
generic algorithms implemented with templates. Sorting is one
case, where C has to use void* and a comparison function,
removing any possibility of inlining (see qsort).

That's a slightly different situation. C++ definitly offers the
programmer significant means of writing faster code, and in
practice, C++ code will almost always run a lot faster than C
code, for this reason. The template thing is only a small part
of this. Generally speaking, you develop code a lot faster in
C++, which leaves you more time for optimizing, if necessary,
and C++ encapsulates better, which means that you can optimize
whatever turns out to be critical without having to rewrite the
entire application.

What I was thinking about, however, is what the compiler can do.
One of the better optimizing compilers I've seen was for
Modula-2, and it very definitely took advantage of all of the
information provided by the language structures. (In this case,
program flow---the compiler practically stopped optimizing
anytime it saw a goto or a label, supposing that program flow
was unknown. Of course, it's possible to reconstruct this
information from scratch, and modern compilers do, but it is a
lot of work.)

In practice, I doubt that many C++ compilers do exploit this
type of information. For one thing, they often share a back-end
with other languages, and the intermediate language has no
provision for communicating this information. And for another,
C++ continues to support all of the bad practices of C as well,
and the compiler has to be able to deal with them. But
theoretically, the fact remains that the more information a
compiler has concerning intent, the more possibilities it has to
potentially optimize.

 

[Bo Persson]

Care to prove that?

Sure.

In C++ everything is a class using multiple inheritance and dynamic
allocation. All funtions are virtual, always.

In C everything is an int, allocated to a register. Much more
efficient!


Bo Persson