Why do people still use C instead of C++ ?
Lawand
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.
Ian Collins
Have you ever tried to find a C++ compiler for a PIC?
--
Ian Collins
Rolf Magnus
Not sure about PIC, but there is one for AVR.
pau...@mbnet.fi
> benchmarking so, why does any programmer on earth still use/learn/
> teach C instead of C++?
For many reasons. Usually people have irrational reasons for
using thing X. That's how people are. Even I was like that and
I'm a genius.
Lawand
That's something I haven't thought of, but let's say there isn't, in
that case, is the lack of C++ compilers for micro controllers means
that there can't be, or means that there shouldn't be.
Or maybe they didn't design one because it's complex.
Anyway, it's not what I am wondering about, what I don't know the
reason of, is writing code (for CPUs, not micro controllers) such as
OS kernels in C instead of C++.
I mean, why bother using C where there exist a more programmer
efficient and faster counterpart, the C++ ?
maverik
Probably, it's better to use a tool that is better suited to your
task. So it depends.
For example, you want to eat a plate of soup. You have 2 ways: you can
use a spoon or an excavator shovel. It is well known that shovel more
powerful tool for rake and beats the spoon. So, should you use
excavator shovel? Probably not. And why? Because, a spoon can solve
this problem more efficiently that the excavator shovel.
blargg
> On Dec 26, 1:11=A0am, Lawand <lawan...@gmail.com> wrote:
> > Hello.
> >
> > AFAIKnew, people used to choose C over C++ as a programming language
> > for their projects because it posses better performance and execution
> > 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.
>
> Probably, it's better to use a tool that is better suited to your
> task. So it depends.
>
> For example, you want to eat a plate of soup. You have 2 ways: you can
> use a spoon or an excavator shovel. It is well known that shovel more
> powerful tool for rake and beats the spoon. So, should you use
> excavator shovel? Probably not. And why? Because, a spoon can solve
> this problem more efficiently that the excavator shovel.
But let's say you regularly eat a plate of soup at a place where, for some
odd reason, they don't provide utensils. You also sometimes do shoveling
when you're out. You'd bring a spoon and the excavator shovel, and use the
spoon for the soup. C++ gives you both, and you don't have to use anything
more than the spoon when metaphorically eating soup. You always have the
option of using a more fancy spoon, also part of C++, building your own
spoon, or (mis)using the shovel. The choice is yours. So why would C++ be
ill-suited in a situation where C is suited?
jason.c...@gmail.com
> 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++?
You must not have read the article, or you're here trolling. It was an
RB-tree implemented in C++ vs. a hash table implemented in C. At the
bottom of the article, it clearly states:
"But this benchmark is no good for the purpose of the "C versus C++"
argument - it's two completely different approaches that yield
completely different results, for reasons that have nothing to do with
the languages used."
There's not, actually, a difference in performance between the two.
They're both compiled to native code, frequently by a compiler that
handles both languages at once, using the same logic for compilation.
Check out the code your compiler generates. A performance difference
between the two languages wouldn't actually make any sense. Any byte
code you produce from C++ can be produced almost identically with C,
except it will take you a heck of a lot longer to express it in C. The
only big difference in "performance" is your algorithms, as shown in
the article.
I guess you missed that part?
> Shouldn't C++ have replaced C? even when developing an OS kernel or
> such sensitive software.
You're welcome to port the existing Linux kernel (for example), to C+
+. While you're working on it, you can reflect on why nobody else has
done it yet.
Most of the time the reasons are that you are maintaining code written
in C or you are on a platform that nobody has bothered to write a C++
compiler for (e.g. PIC). A lot of programmers raised on C will stick
to C because it's what they know, with logic like "well if you're not
going to use the features of C++, you might as well use C". An
experienced C programmer has techniques that he's comfortable with and
simply doesn't see a need to switch. I guess that's reasonable, who
knows (or cares)?
C++ also took a bit of time to become accepted because early (e.g. mid
90's) compilers were strange and quirky. This also probably left a bad
taste in the mouth of those who attempted to learn it at the time.
Most C++ compilers are mature enough now that it's no longer an issue.
HTH, and next time read the article.
Jason
jason.c...@gmail.com
This is a really silly analogy that shouldn't have been made in the
first place. Not quite sure why programmers are so keen on ridiculous
analogies all the time. It's not even necessary, and doesn't make all
that much sense. "C++ gives you both a spoon AND a shovel but C only
gives you a spoon OR a shovel" isn't really a compelling statement
of... anything at all. Sorry.
Mentioning the word "efficient", in the context of performance, is
also irrelevant. The languages are the same and the article does not
actually attempt to show a "performance" difference between the two
(go read it).
The article does explain that C is more verbose for certain tasks. The
compiled code is not going to differ that much between the two. You
can express the same programs with both, you just have to type more
with C sometimes.
HTH,
Jason
Lawand
Calm down :)
Now, are you saying that, as a conclusion, C++ is better than C
(because there's no difference in performance, yet C++ has more
features), but programmers still use C just because they're used to?
And in that case, all newbies should be advised to learn C++, right?
Rui Maciel
> Calm down :)
Trolls don't usually make people get calmer.
> Now, are you saying that, as a conclusion, C++ is better than C
> (because there's no difference in performance, yet C++ has more
> features), but programmers still use C just because they're used to?
You are putting words into jason's mouth. You failed to read the article and jason pointed out that even the article clearly stated that their benchmarks could not be used to compare the languages in those silly and pointless "language A Vs language B" discussions, which was what you promptly did.
Moreover, C and C++ are two different languages that scratch different itches. The only person that keeps forcing the "language A is better than language B" conclusion is, well... you.
Rui Maciel
Laurent Deniau
C++ is not a super set of C and is much more complex which means that
"average" C++ programmers may have some difficulty to predict the
behavior of their code. There is also things which are "easy" to do in
C and nearly impossible in C++. I have been using C++ from 1989 to
2006 and switch back to C for this reason once I found the programming
techniques that fit my needs. Before doing the switch, I used (and
abused) templates and I studied in depth the C++ object model to
understand what I could(n't) do. As already said, the best is to use
the language that fits your needs.
a+, ld.
Giuliano Bertoletti
There are a lot of reasons.
Development of most OSes started long time ago when C++ compilers
weren't mature and most C++ features (like templates) were not well
understood, leading to different (and possibly wrong) results depending
on the compiler (I remebmer Microsoft compilers giving up compilation
with an "internal compilation error").
Migrating a project that started in C to C++ means a lot of effort; even
simply upgrading the compiler could lead to problems with an otherwise
working environment.
Also, the APIs that an OS exposes to applications (and drivers) should
have a C-style linkage, otherwise that would break compatibility with
almost everything.
Even when creating libraries in binary code, exporting a C interface is
ofter preferable.
C is far more easier than C++ to learn, so if you do not need C++
features why bother learning C++ (and even when you do, nowadays time
may be better spent on other high level languages, depending on what you
have to do).
Code portability is another issue. Being C simpler than C++ it tends to
create less troubles when porting code to another compiler/platform.
Performance can still be an issue because there may be hidden
complexieties that the compiler handles for you trasparently at the
price of more machine instructions executed.
Regards,
Giuliano Bertoletti
Bo Persson
There are OS kernels written in C++, like Symbian, so it is very
possible.
The main reason for the major operating systems is that they have been
around since before C++ became a viable option. They were started out
in C, and has kept this tradition.
Bo Persson
Bo Persson
>
> C++ is not a super set of C and is much more complex which means
> that "average" C++ programmers may have some difficulty to predict
> the behavior of their code. There is also things which are "easy"
> to do in C and nearly impossible in C++.
I am really curious here - wanna give some examples?
Bo Persson
jason.c...@gmail.com
> (because there's no difference in performance, yet C++ has more
> features), but programmers still use C just because they're used to?
No.
> And in that case, all newbies should be advised to learn C++, right?
No.
It seems you read my post about as closely as you read that article.
Jason
perl...@yahoo.com
> such sensitive software.
I'm reminded of Linus Torvalds' big rant against C++ last year. Google
"linus torvalds c++" and read his posts at gmane.org for another
opinion.
James Kanze
> On Dec 26, 1:40 am, Ian Collins <ian-n...@hotmail.com> wrote:
> > > 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.
> > Have you ever tried to find a C++ compiler for a PIC?
> That's something I haven't thought of, but let's say there
> isn't, in that case, is the lack of C++ compilers for micro
> controllers means that there can't be, or means that there
> shouldn't be. Or maybe they didn't design one because it's
> complex.
Or because their competitors didn't, so they don't feel the need
to.
> Anyway, it's not what I am wondering about, what I don't know
> the reason of, is writing code (for CPUs, not micro
> controllers) such as OS kernels in C instead of C++.
Most OS kernels for modern general purpose machines do contain
quite a bit of C++. Significant parts of the many of the
kernels, however, were written before C++ was generally
available.
> I mean, why bother using C where there exist a more programmer
> efficient and faster counterpart, the C++ ?
Mainly habit and existing code.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Rolf Magnus
>> Now, are you saying that, as a conclusion, C++ is better than C
>> (because there's no difference in performance, yet C++ has more
>> features), but programmers still use C just because they're used to?
>>
>> And in that case, all newbies should be advised to learn C++, right?
>
> C++ is not a super set of C
It can be used as one.
> and is much more complex which means that "average" C++ programmers may
> have some difficulty to predict the behavior of their code. There is also
> things which are "easy" to do in C and nearly impossible in C++.
Which would that be? Most C code can be put through a C++ compiler with only
a few minor changes.
> I have been using C++ from 1989 to 2006 and switch back to C for this
> reason once I found the programming techniques that fit my needs. Before
> doing the switch, I used (and abused) templates and I studied in depth the
> C++ object model to understand what I could(n't) do. As already said, the
> best is to use the language that fits your needs.
I can see uses of templates even down to the smallest microcontroller
devices (and have actually used them there).
Laurent Deniau
google for "C Object System" or go to sourceforge. COS itself cannot
be implemented in C++ AFAIK and it would be very complex to implement
even by a C++ compiler ("The good is the enemy of the best"). It
provides the dynamic counterpart of the template, that is multi-
methods which I consider to be more important than templates.
Obviously, if I could have both, it would be even better. Another
feature that I consider very important is the (generic) delegation and
it can only be implemented on top of messages.
a+, ld.
Laurent Deniau
> Laurent Deniau wrote:
> >> Now, are you saying that, as a conclusion, C++ is better than C
> >> (because there's no difference in performance, yet C++ has more
> >> features), but programmers still use C just because they're used to?
>
> >> And in that case, all newbies should be advised to learn C++, right?
>
> > C++ is not a super set of C
>
> It can be used as one.
>
> > and is much more complex which means that "average" C++ programmers may
> > have some difficulty to predict the behavior of their code. There is also
> > things which are "easy" to do in C and nearly impossible in C++.
>
> Which would that be? Most C code can be put through a C++ compiler with only
> a few minor changes.
I would be very interested (honestly) by the "few minor changes" to
apply to COS (C Object System) to be able to compile it with a C++
compiler. It compiles with a C99 compiler or even with a C99
(standalone) preprocessor and a C89 compiler.
> > I have been using C++ from 1989 to 2006 and switch back to C for this
> > reason once I found the programming techniques that fit my needs. Before
> > doing the switch, I used (and abused) templates and I studied in depth the
> > C++ object model to understand what I could(n't) do. As already said, the
> > best is to use the language that fits your needs.
>
> I can see uses of templates even down to the smallest microcontroller
> devices (and have actually used them there).
I didn't say that you can't or it's useless. I just say that I tried
to implement some features (e.g. multi-methods, messages) which I
consider today to be very important in a language and failed to do it
in C++ while it was relatively easy to do in C.
a+, ld.
jason.c...@gmail.com
> On 27 déc, 20:24, Rolf Magnus <ramag...@t-online.de> wrote:
>
>
>
> > Laurent Deniau wrote:
> > >> Now, are you saying that, as a conclusion, C++ is better than C
> > >> (because there's no difference in performance, yet C++ has more
> > >> features), but programmers still use C just because they're used to?
>
> > >> And in that case, all newbies should be advised to learn C++, right?
>
> > > C++ is not a super set of C
>
> > It can be used as one.
>
> > > and is much more complex which means that "average" C++ programmers may
> > > have some difficulty to predict the behavior of their code. There is also
> > > things which are "easy" to do in C and nearly impossible in C++.
>
> > Which would that be? Most C code can be put through a C++ compiler with only
> > a few minor changes.
>
> I would be very interested (honestly) by the "few minor changes" to
> apply to COS (C Object System) to be able to compile it with a C++
> compiler. It compiles with a C99 compiler or even with a C99
> (standalone) preprocessor and a C89 compiler.
I had wanted to take a stab at it, but:
1. COS is not actually available on SourceForce except through CVS.
Not very convenient.
2. The COS Makefiles do not build. It appears you used something like
autoconf but did not actually include a configure script in CVS. 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.
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.
> > > I have been using C++ from 1989 to 2006 and switch back to C for this
> > > reason once I found the programming techniques that fit my needs. Before
> > > doing the switch, I used (and abused) templates and I studied in depth the
> > > C++ object model to understand what I could(n't) do. As already said, the
> > > best is to use the language that fits your needs.
>
> > I can see uses of templates even down to the smallest microcontroller
> > devices (and have actually used them there).
>
> I didn't say that you can't or it's useless. I just say that I tried
> to implement some features (e.g. multi-methods, messages) which I
> consider today to be very important in a language and failed to do it
> in C++ while it was relatively easy to do in C.
Why did you fail to do it in C++? What specific problems are you
referring to? Issues with... type checking or something? 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++".
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. 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++...
Same deal with messaging systems, which are just as trivial to
implement in C++ as they are in C.
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. 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.
Laurent Deniau
<jason.cipri...@gmail.com> wrote:
> On Dec 27, 6:58 pm, Laurent Deniau <Laurent.Den...@gmail.com> wrote:
>
>
>
> > On 27 déc, 20:24, Rolf Magnus <ramag...@t-online.de> wrote:
>
> > > Laurent Deniau wrote:
> > > >> Now, are you saying that, as a conclusion, C++ is better than C
> > > >> (because there's no difference in performance, yet C++ has more
> > > >> features), but programmers still use C just because they're used to?
>
> > > >> And in that case, all newbies should be advised to learn C++, right?
>
> > > > C++ is not a super set of C
>
> > > It can be used as one.
>
> > > > and is much more complex which means that "average" C++ programmers may
> > > > have some difficulty to predict the behavior of their code. There is also
> > > > things which are "easy" to do in C and nearly impossible in C++.
>
> > > Which would that be? Most C code can be put through a C++ compiler with only
> > > a few minor changes.
>
> > I would be very interested (honestly) by the "few minor changes" to
> > apply to COS (C Object System) to be able to compile it with a C++
> > compiler. It compiles with a C99 compiler or even with a C99
> > (standalone) preprocessor and a C89 compiler.
>
> 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.
> > > > I have been using C++ from 1989 to 2006 and switch back to C for this
> > > > reason once I found the programming techniques that fit my needs. Before
> > > > doing the switch, I used (and abused) templates and I studied in depth the
> > > > C++ object model to understand what I could(n't) do. As already said, the
> > > > best is to use the language that fits your needs.
>
> > > I can see uses of templates even down to the smallest microcontroller
> > > devices (and have actually used them there).
>
> > I didn't say that you can't or it's useless. I just say that I tried
> > to implement some features (e.g. multi-methods, messages) which I
> > consider today to be very important in a language and failed to do it
> > in C++ while it was relatively easy to do in C.
>
> 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
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...@gmail.com
> 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 ,
Bo Persson
Very nice! :-)
Perhaps another item for the Abridged FAQ?
Bo Persson
co...@mailvault.com
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
>On Jan 2, 7:08=A0pm, Greg Herlihy <gre...@mac.com> wrote:
>> On Dec 25 2008, 2:11 pm, Lawand <lawan...@gmail.com> wrote:
>>
>> > Hello.
>>
>> > AFAIKnew, people used to choose C over C++ as a programming language
>> > for their projects because it posses better performance and execution
>+/
>> > 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.
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.
>> 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.
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. Yes, it does help a lot on
application level where you can afford the performance
losses. Sure, your more abstract view of computation
reduces to cleaner, more structured programs, but what is
C++ class object to begin with?
Well, it is a C structure. Nothing more.
So...
>> Nevertheless, despite the clear incentive to fix this crisis, efforts
>> to reach this group of afflicted programmers
What "crisis"?
What "afflicted" programmers?
Why do you need to make them look sick?
Do you have a slightest idea of what they are doing?
I tell you one thing, if you come to certain departments,
where the CORE issues are resolved, and pump your chest
as C++, holier than though, programmer, they're just gonna
laugh at you and quickly move away.
Because your talk is simply infantile.
What are you trying to concoct here?
Enough for now.
pgadmin
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
> In article
> <5740713c-c2f3-427e-aa5a-65864477b...@z28g2000prd.googlegroups.com>,
> c...@mailvault.com wrote:
> >On Jan 2, 7:08=A0pm, Greg Herlihy <gre...@mac.com> wrote:
> >> On Dec 25 2008, 2:11 pm, Lawand <lawan...@gmail.com> wrote:
> >> > 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=3D"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.
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.
> >> 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.
> 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.
s0s...@gmail.com
> 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
> 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
"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
> On Jan 4, 4:47 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jan 4, 8:46 am, pgad...@pg.invalid (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.
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
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.
>
--
Ian Collins
Ian Collins
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).
--
Ian Collins
Chris M. Thomasson
news:gjppgh$3qb$1...@solani.org...
> In article
> <5740713c-c2f3-427e...@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
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
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
Daniel Pitts
references or explanation of how you came to that conclusion.
Unless... Are you're being facetious and I missed it?
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Jeff Schwab
> Bo Persson wrote:
>> Ian Collins wrote:
>>> pgadmin wrote:
>>>> At the kernel level, there is a difference between C and C++.
>>>> The penalty in performance is probably around 50%, AT LEAST,
>>>> compared to pure C.
>>>>
>>> Care to prove that?
>> 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! :-)
> That is hardly a proof of anything. Especially since there are no
> references or explanation of how you came to that conclusion.
>
> Unless... Are you're being facetious and I missed it?
Are you any relation to this guy?
http://groups.google.com/group/comp.lang.c++/msg/f4d67a2fc52b6b43
Bo Persson
Probably. :-)
That was my impression of why some people don't like C++, including
Linus Torvalds.
The argument seems to be that it is easier to write bad code in C++
than in C. Some of us argue that it is also easier to write good code
in C++.
Bo Persson