

Why C++ is vastly superior to C - tree_of_item
http://warp.povusers.org/programming/cplusplus_superior_to_c.html

======
jerf
When the argument is that C++ has too many features that interact in
unpredictable ways and are virtually impossible to get right, arguing that C++
is superior because it has more features is perhaps a fine argument in some
hypothetical universe in which the primary objection to C++ is that it is
missing features, but by failing to grapple with the points raised by the
opposition in the real universe, you will fail to convince anybody. Everybody
already knows all of these features, they're practically in the canonical
Introduction to C++ pitch, and they _still_ don't think C++ is great. Maybe
you need to spend a bit more time listening more carefully to why; you
_certainly_ need to if you expect to talk anybody out of it.

~~~
vixeria
What are some of these C++ features that interact in unpredictable ways? Just
curious.

~~~
implicit
Implicit conversions come to mind. They don't need to interact with anything
to be confusing.

Consider this program:

    
    
        #include <iostream>
        using std::cout;
        using std::endl;
    
        struct C {
            int x;
            C(int _x) : x(_x) {}
    
            operator bool() const { return 0 != x; }
        };
    
        struct D {
            float f;
            D(float _f) : f(_f) {}
    
            operator bool() const { return 0.0f != f; }
        };
    
        int main() {
            C c(9);
            D d(2.0f);
    
            if (c == d) {
                cout << "Equal" << endl;
            }
    
            return 0;
        }
    

g++ 3.4.4 doesn't so much as warn that something is fishy here, even with
-Wall.

Not only that, but c and d are considered to be equal.

~~~
mnutt
Maybe it's just coming from a dynamic language, but it appears that you've
overridden the bool operators to always return true. (except when you pass in
0 and 0.0) If you redefine how two structs of different kinds are compared,
who is the compiler to say it's a problem?

~~~
spullara
In most dynamic languages 0 is false and anything else is true but it normally
wouldn't use that information to coerce two values of different types to
booleans before comparing them.

~~~
mnutt
I'm only aware of php and javascript equating 0 to false. But at any rate in
this case it's not equating 0 to false, it's comparing non-zero to zero and
returning true. (as it should)

~~~
burgerbrain
In C, 0 evaluates to false.

------
ColinWright
<fx: sigh>

For some things, C++ is better than C. For some things Lisp is better than
either, and for yet other things, Python is better than them all.

Why are people so insistent on declaring their view is absolutely right, with
no arguments, everyone else is wrong, and that one language will rule them
all?

Trust me. For some things I do, C is vastly superior to C++, but I'm not going
to try to convince everyone that C is better than C++ (or anything else) for
everything that anyone wants to do.

That would just make me look stupid.

~~~
tree_of_item
I don't think this article is about declaring C++ the ruler of all languages.

If you have an example of C being a better fit for a problem than C++, feel
free to share it.

~~~
phirephly
Embedded systems, 128 bytes of RAM. I really do just want portable assembly.

~~~
eropple
But you don't have it, unfortunately. At that level C is just as unsuitable.
Time to break out your assembler. ;)

------
jmspring
I've found that whenever someone argues "X is best", they've only worked in
projects where "X" makes sense for them. At a start up a couple of years ago,
we had an intern that was all hot and bothered over C++ and boost. After he
expanded is horizons to web development and investigating scripting languages,
he really enjoyed Ruby.

It depends on what you are working on, the libraries and tools available, and
your comfort with what languages fit that paradigm.

I use C++ and Java on a regular basis now, but prefer C for systems
programming, and Python for general web/scripting stuff.

Since we need to have a nit with C++ for this thread, can someone explain to
me how debugging in C++ while using templates is superior?

~~~
eropple
The answer to your question is "use Visual Studio." ;-) Or, at least, use
clang. The gcc stack is pretty poor at dealing with templates, and its
debugger is pretty baroque.

------
jergosh
This post boils down to "Take C, add support for OO, a crapload of new syntax,
standard library that 10x as large and ta-da! you can find problems which have
simpler solutions than in C."

There's a great post by Linus Torvalds about C vs. C++ in the kernel. Some
excerpts:

"My point being, that C++ adds absolutely nothing interesting."

"C++ is a mess. There's no design. It's just "add crud on top of C". And the
crud isn't even meaningful, much less does it have a design. It's totally and
utterly random.

It started out random, now it's randomness that gets added to by a committee."

Whole thing:
[http://www.realworldtech.com/forums/index.cfm?action=detail&...](http://www.realworldtech.com/forums/index.cfm?action=detail&id=110577&threadid=110549&roomid=2)

~~~
tree_of_item
The author of the OP has a pretty well written rebuttal to everything Torvalds
has said about C++:

<http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html>

~~~
IvarTJ
That article is not very informative, and spends a lot of time characterizing
Linus as someone with the “C-hacker syndrome.”

~~~
yannickt
I find the article to be vastly more informative than most of Linus' posts
about C++, which usually read more like rants than _well informed_ criticism.
He does not characterize Linus as a "C-hacker", Linus does that himself by
posting an opinion about C++ that completely lacks substance.

------
tzs
The problem with C++ is that the language is too damn big. This results in
most programmers only learning really well a subset of the language.

Unfortunately, different programmers end up with different subsets.

I'd like to see some de facto standardization on subsets. For instance, there
could be Basic C++. When programming Basic C++ you use it like C with the
following C++ features added: constructors, destructors, references,
std::string, and maybe the STL collections.

Simple Object C++ could be Basic C++ plus single inheritance.

The on top of that, we could add things like multiple inheritance, operator
overloading, templates, and so on.

~~~
thedigitalengel
Most projects have a set of coding guidelines. I don't see why it cannot
specify things like: "Don't use operator overloading!".

Google does, for one thing.

Without discipline both C and C++ will blow you up completely. With some
discipline both the languages are manageable, and C++ more so; which is what
the OP points out.

~~~
peterbotond
that's exactly right and correct. any language can be screwed up without
descipline, and understanding of the solution trying to be implemented. me for
example, put comments in code that what direction of design, execution path is
taken to correct less efficient idioms. so, at a later time, new code can be
added with some direction. this prevents the urge to copy and paste by the new
guy.

coding guidelines are also to include programming idioms, primitives, to use
and build the solution around it.

for c++, c and others i wrote many of guidelines, and seeing the benefit later
i can say the above.

------
AshleysBrain
Apart from "use the right tool for the job", I always did wonder how C
programmers cope without the STL containers: std::vector, std::list, std::set,
std::map etc.

Sometimes I need to map a string to a list of numbers. std::map<std::string,
std::vector<int> >. Done. All memory allocation taken care of for you as well
- nothing to leak. In C, how do you get by? You either have to reinvent a red-
black tree each time you want that, or use some kind of type-unsafe macro
horror, or just not use that data structure.

That seems to be a significant point of the article as well. Any C programmers
care to enlighten me on this? Nowadays I couldn't code for long in C without
thinking "screw this, I want a vector" and going back to C++.

~~~
edderly
Fair point, but in systems programming where C is used a lot, the 'system'
often/usually has the abstract data types you need, or you're in a lower level
enough environment that you want your own custom/hardware specific solution.

Crude example: <http://kernelnewbies.org/FAQ/LinkedLists>

------
ctz
Counterpoint to the C++ fragment in "Error handling" section:

    
    
      void foo()
      {
        Matrix *a = new Matrix(1000, 1000);
        Matrix *b = new Matrix(1000, 1000);
        
        delete b;
        delete a;
      }
    

Pretending exceptions solve error handling gets you a big fat zero. Look at
boost: despite being written by C++ experts and held up as an excellent
library (which it is!), it contains exception-unsafe portions. Why? Total
exception safety is just as hard as the original error handling problem.

~~~
simoncion
Counterpoint to your counterpoint:

    
    
      void foo()
      {
      	typedef std::auto_ptr<Matrix> matAP;
      	matAP a(new Matrix(1000, 1000));
      	matAP b(new Matrix(1000, 1000));
      }

------
Spyro7
I know that C++ has some pretty neat features, but I feel comfortable and
productive enough in C. I have never really felt that there was anything in
C++ that I just _had_ to have.

If I need to something higher level there are plenty of choices of that
already, and C is a great language for extending applications done in a higher
level language.

I think that the author has some good points. but I think both languages have
the places where they excel.

To say that one is "vastly superior" to the other is a mistake. If C++ was
really "vastly superior" to C then why are so many people still using C and
using it productively?

~~~
mojuba
> If C++ was really "vastly superior" to C then why are so many people still
> using C and using it productively?

Why are so many people using Java (perhaps even more than C and C++ combined)?
Does it make a good language? Absolutely not. In the case of such simplistic
languages as C and Java, it's their simplicity that makes them a popular
choice.

Productivity: I am not sure all the C folks are as productive as they could've
been if they switched to C++. Same people.

The complexity of C++ is not only in the amount of new concepts compared to C,
it is also in greater risks of producing bloated binaries. Too much knowledge
and caution is required to keep C++ code maintainable in this regard. That's a
drawback, but if you ask me, I'd never give up RAII, implicit destruction and
exceptions for C; I'd rather understand them better in order to use them
properly.

And finally, the article would look much nicer without the insults closer to
the end.

~~~
Spyro7
"Why are so many people using Java (perhaps even more than C and C++
combined)?"

Well, one contributing factor is that a lot of universities now have a heavily
Java based curriculum (turning their CS programs into vocational schools, but
I digress).

Another contributing factor is that Java has managed to carve itself a niche
in which it is used extensively ("enterprise" applications - with all of the
wonderful ambiguity that the word "enterprise" carries nowadays).

One more thing in Java's favor is just simple momentum. There are a lot of
Java libraries that just plain work (and some work extremely well). There are
a lot of applications on the corporate side that use Java.

Regardless of whether you or I like the language or not, Java has apparently
proven itself useful to a broad swathe of people. It may not be an exciting
language, but then neither is Cobol and it still exists as well (and puts food
on quite a few tables).

Then there is the venerable JVM, which is actually an amazing piece of
software engineering that has enabled the development of a wave of innovative
new languages. Of course, one of the features of many of these new languages
is the ability to drop down into Java for speed (now before anyone starts
sneering, Java is actually not doing to bad on that front right now).

"Does it make a good language? Absolutely not."

Perhaps not in your opinion, but their are others who are quite fond of it.
That's the problem with these type of pronouncements. What makes a "good
language" varies from person to person.

Disclaimer: I have used Java for some small projects in the past - I may be
somewhat biased.

 _Edit: Embarrassing grammatical flaws._

~~~
mojuba
I know Java is practical within certain contexts and for certain class of
people, but our judgement of what's good or bad in general shouldn't really be
a matter of taste and preference. Are we an engineering discipline or what?

What we call a matter of preference is actually things that go beyond
engineering. We may have emotional ties to programming languages ("I love
Java", "I hate C++") because of job security, because of often subconscious
fear of inability to learn new stuff, and so on. We should clean up the table
from the psychological aspects of the matter and look at what's left: that's
how powerful and how clever a language can be in the hands of a good
developer.

Java is a terribly verbose and an embarrassingly simplistic language. C is
simplistic and can be considered dead the day C++ compilers catch up with
speed and memory allocation, which will make it suitable for embedded
programming too.

(And BTW, I don't mind JVM, it probably is a fantastic piece of engineering,
except... for reasons I don't understand very well, a simple "Hello world"
application written for JVM can take seconds to load and execute. I've heard a
thousands reasons none of which made much sense. As well as promises JVM will
be improved in the future. First time I heard this was 15 years ago, still no
progress.)

~~~
Spyro7
"our judgement of what's good or bad in general shouldn't really be a matter
of taste and preference. Are we an engineering discipline or what?"

You know what. It's a funny thing, but as I was typing my response to your
original post, I actually said this exact same thing to myself, and I started
to think. It would be incredible if there was some non-emotional, non-touchy-
feely way to get at the value of one language vs another. But then programming
language choice just seems to be an inherently "feel" based decision...

"We should clean up the table from the psychological aspects of the matter and
look at what's left: that's how powerful and how clever a language can be in
the hands of a good developer."

This is one of the things that I thought of, but then there are so many
demonstrations of people using all kinds of programming languages to do things
that are incredibly clever and powerful.

Sometimes I like to just go through open source projects written in
programming languages I am not extremely familiar with. I just want to get a
taste of some of the myriad of programming styles and techniques that are out
there. The different ways of looking at the same problem.

Even if I disagree with the method used, it is always eye-opening to see other
ways of doing things - even some that may be vastly different from anything
that I have ever seen before (my first time looking at Haskell comes to mind).
I like to understand how and why different developers choose the routes that
they choose.

I don't know, but to me it seems that, in a way, it is good that there is no
emotionless method for rating languages. To declare one language as being
definitively better than all others seems to me that it would be a tremendous
loss. There is some value, I think, in having a diversity of "good" languages
just for its own sake.

As to the simplicity of a language, well, to some people simplicity in a
programming language is a beautiful thing, but then, the problem is that what
constitutes simple is also a thing that varies from developer to developer.
Perhaps the diversity of languages is a natural development from the diversity
of programmers?

I think about Ruby. You know, when Matz describes why he created the language,
he says that he wanted to create something that felt fun to develop in - fun
for him. The fact that other people just happened to like Ruby was an
unintended side effect.

I think that most people create a programming language with a similar type of
outlook. They, either purposefully or subconsciously, try to build it to
achieve a certain "feel". Perhaps it is this "feel" that makes a good
developer powerful and clever with a language.

"for reasons I don't understand very well, a simple \"Hello world\"
application written for JVM can take seconds to load and execute."

Heh heh, I have no comments on that.

~~~
mojuba
Generally agreed, except: let's be careful with the notion of simplicity. I
used the word "simplistic" which bears some negative flavor (pointlessly
simple?). Lisp is relatively simple and yet powerful, i.e. it is not
simplistic. C++ is incredibly complex (dare to write a full blown modern C++
compiler?) and powerful. Not surprisingly though, the simplicity of Lisp
doesn't make it easier to grasp.

From this point of view, languages that are neither complex nor allow for
complexity can be called "simplistic". They are easy to learn, easy to write
code in, and as easy to grow to unmaintainable sizes because of their
verbosity. Since we have very few readers here at the bottom of the thread, I
will admit that every time I see all kinds of dancing around class
instantiation, endless method calls etc in Java, where in some other language
it would take a single function call, it reminds me of how kids count the
steps out loud when they go up or down the stairs. When you grow older, you
don't count any more, it's kind of implied :)

And I haven't found a better measure of quality of programming languages than
that proposed by Paul Graham here: <http://www.paulgraham.com/power.html>

Edit: just noticed downvotes for my previous comment, so no, we are not alone
:)

~~~
Spyro7
mojuba, I have to thank you for that link. I confess that I had never read
that document prior to today. The thing that I like most about it is that he
leaves it open ended.

He doesn't pretend to have all of the answers but rather invites the reader to
embark on a thought exercise. Ignoring the question of comparing languages,
that is an excellent example of how to write concerning this type of topic.

On comparing languages, I have to say that comparing languages based on power
does make sense - with power defined as programmer productivity. From this
perspective, I can understand your view on Java.

But is it the language itself that is to blame or the spaghetti code that all
too often results from inexperienced users? I recall that the JRuby team has
done some interesting things within the limitations of the Java language.

 _Note: To those who down-voted the original comment, I did not think that the
down-voting is the most optimum solution for when you have a different
perspective on an issue. Wouldn't it be better for everyone to chime into the
discussion and increase everyone's knowledge with your perspective on the
issue? This type of thing is why I have to ignore votes and just try to
learn._

------
wmobit
The containers problem is the only one I find really annoying, and is more of
a problem with the C standard library than the language. Using C with
something like glib is a much nicer experience.

~~~
uriel
If you can't write your own linked lists or hash tables, you should not be
programming in C. Glib is an abomination by people and for people that didn't
understand C. Just like GNU is by people and for people that didn't understand
UNIX.

~~~
andrewcooke
ugh. you're using c? that's just an abomination for people that don't
understand assembler.

------
mklencke
The RAII benefits are definitely there and STL containers are pretty awesome,
but you can still create generic containers in C by using void pointers. For
example, a simple vector API:

    
    
      typedef struct { void *elements; int elem_size; int n; } Vector;
    
      Vector *vector_new(int elem_size);
      void vector_free(Vector *v);
      void vector_push(Vector *v, void *elem);
      void vector_pop(Vector *v);
      int vector_size(Vector *v);
      void *vector_at(Vector *v, int i);
    

etc. This is off the top of my head, but you get the idea. You can basically
put anything you want in there as long as you say how large the elements are
upon initialization.

There is a good book on generic C programming:
<http://sites.google.com/site/cinterfacesimplementations/>

~~~
rbonvall
The problem with using void* pointers is that every access to an element costs
one extra dereference operation. By using C++ templates, the compiler can
create object code specifically compiled for each data type, without the need
for pointers. (On the other hand, this can make C++ binaries much larger).

~~~
mklencke
In this case, I'm not storing void pointers in the data structure, but I'm
using the void pointer as a direct address into "elements". The memory layout
is just a sequence of items of length elem_size. vector_push copies the item
into that memory (and doubles the size of "elements" with realloc when
necessary).

~~~
anonymous246
So you have a memcpy() call in vector_push? I wonder if that's less efficient
than a straight-up assignment for small objects such as integers. The C++
equivalent can be further optimized during instruction generation by keeping
things in the CPU registers as long as possible. In your C case, the int has
to be written to memory before memcpy can load it into its buffer.

~~~
mklencke
True, but that can be overcome by another function that just gives you an
address to put a new item. You would say, for example:

    
    
      *(int *)vector_expand(v) = 2;

~~~
anonymous246
This is a super-unclean API, but that's just IMHO.

We'll just have to agree to disagree that what you've shown above is an
acceptable API for a vector module.

~~~
mklencke
I'm just making it up as I go along, it's not the prettiest thing. What would
you do, in C?

------
malkia
highly opinionanted article. C++ breaks at places, where the compiler is
instructed to not optimize (debug builds), and say operator overloading have
been used for simple types, which creates function calls, rather than inlining
it, while "C" approach (functon calls) would've worked not so slow. Talking
from real experience, after coworker rolled heavy templated C++ math library
for all consoles and PC, that worked very good in release, but debug builds
crawled to 10 times slower.

The problem is that this library forced everyone to use it's types,
interfaces, etc. - so the effect was spreading everywhere. Instead you should
only do such things isolated, and provie "c" interface (for example zeromq
does that).

Also do not propagate exceptions to client, especially if you are some
middleware not used for the core of the things (for example social service
api, advertisement api, or anything small used just as service).

Better do exceptions internally, and provide error codes or callbacks for
client. Exceptions do not work on certain very popular gaming devices for
examlple, and the user of your library might want to avoid them for other
reasons

so do your best C++ in secret, if you want, provide us C interface

------
danieldk
As usual, use the right tool for the job. Personally, I use C++ mostly, for
different reasons:

\- There are some very good cross-platform toolkits available for C++ (such as
Qt).

\- There is no C99 support in Visual Studio. At the same time, C++-98 works
across all major compilers these days.

\- STL containers.

However, C++ just is the best choice for the projects I am currently working
on. For other projects, with fewer dependencies and no portability
requirements beyond Unixy environments I prefer C.

Nearly any language can be superior, depending on the project. The linked
article attempts to show that C++ is superior based on some specific
situations where this may indeed be the case.

------
edanm
Interesting article. One major problem - it doesn't seem like the OP has ever
actually _used_ C for real world code. I say this as someone with a few years
of experience with C (and a few years of C++).

 _None_ of the examples he showed of C code look like they were actually
written by a C programmer. A lot of use of "goto"'s, for one thing. It looks
like he tried reimplementing C++ in C.

Actually, that's exactly what he decided _must_ be done: " If the C version
wishes to match the C++ version in speed and memory usage, it will have to
basically simulate the C++ implementation using a struct and functions which
handle objects of that struct type (including things like initialization and
destruction)."

So obviously, if you set out from the start with the assumption that to use a
language, you have to reimplement another language in it, then of course
you'll come to the conclusion that you should just use the other language. But
that's _not_ a conclusion that C programmers would be comfortable with.

By the way, as just one nitpick, I'd probably implement that Matrix with "void
*" pointers, letting me substitute any struct I want in there later. Just my
way of solving the "impossible to solve" problem he presents at the end.

------
tszming
If the author changed the title to "Why C++ is vastly superior to C for
application programming", than i would agree for the examples he given in the
article.

~~~
yannickt
I agree with you, however most posts I have seen bashing C++ for its
complexity do it from the perspective of the systems programmer as well. So it
is nice to see someone showing how C++ can be superior.

------
rwmj
This article should be "why C++ is vastly superior to C _for multiplying and
adding 3 matrices if you're not a very good C programmer_ ".

~~~
tree_of_item
So how would a very good C programmer implement this example? I don't think
you can No True Scotsman your way around RAII and templates.

------
IgorPartola
The "final straw" is easily overcome with unions.

Also I do not buy the argument that you do not have to follow coding
conventions in C++ or that explicitly freeing memory is a bad thing. Also
comparing the number of lines of code to determine the "best" language is
childish. By that logic the language with the largest std. lib is the best.

~~~
mojuba
Aside from obvious type safety arguments, you want to combine a 'long long'
and a 'char' into a union, and for example have a byte matrix occupy 8GB of
RAM instead of just 1GB?

If I were to defend C, I'd rather choose macros combined with plain typeless
buffers. The choice between C and C++ in such cases is really a choice between
the nightmare of wrong memory operations and total type unsafety on the one
hand (C), and the nightmare of ineffective, bloated code on the other (C++). I
believe the latter can be taken under control though.

------
16s
C++ gets a bad wrap from people who have never seriously used it. I'm glad to
see someone slapping back. It's a fine language that is very useful and will
be for decades to come.

------
atlei
I don't think _any_ language is vastly superior to any other in _every_ case.

You can say that C++ is vastly _more powerful_ (and flexible) than C, but for
low-level/embedded/kernel etc development, many would argue that C is the
superior language.

Many people would also argue that C++ is maybe _too_ powerful and complex; you
can do everything with it, but sometimes this makes it hard to decide how to
do "anything" (procedural ? Object-oriented ? Using templates ?).

Lots of people (myself included) find it so complex that they only use a
subset of it - "the good parts". However, agreeing which parts to use is often
impossible.

I've written about about what I consider "the good parts" here:

\- <http://www.ppcsoft.com/blog/c-star.asp>

------
starpilot
Novice question: Why is C++ used for the vast majority of video games today?
Why is it used for most commercial CFD codes? (A lot of codes in academia
still use tons of legacy fortran though.)

~~~
sehugg
I think this post sums it up pretty nicely:
<http://www.gamearchitect.net/Articles/WhyC++.html>

Personally I think the advantages boil down to syntax and type-safety. For
example, vector math is much more succinct and can be made type-safe.
Constructors/destructors also can be handy for enforcing resource allocation.

------
blacksmythe
Many people believe that C++ has useful features that improve the ability of
the average programmer to write application programs. One problem is that
different companies use different subsets. (The question of which language the
Linux kernel should be written in is of limited interest.)

We could name a restricted subset of C++ as C+-. Many high quality and well-
tested development tools for C+- already exist (the C++ tools). Now the
problem remains of standardizing C+-. The most logical C+- variant to
standardize on is the C++ subset used by the largest group of people,
presumably the version defined by Google: [http://google-
styleguide.googlecode.com/svn/trunk/cppguide.x...](http://google-
styleguide.googlecode.com/svn/trunk/cppguide.xml#Inheritance)

Now the question becomes is it easier for average programmers to build
application programs using C or C+-? Using C+- or C? These are perhaps more
useful questions than the long running C vs C++ debate.

------
mitchi
"A few of lines of C++ code would need hundreds, if not even thousands of
lines of C code, but an experienced C programmer is used to that."

Yea right. This guy is full of it. This article is very biased...

~~~
eropple
Of course it's biased. It's also not really wrong on a lot of counts. You
really can write more expressive, terser code in C++, that sacrifices no
readability and only a very tiny bit of performance (on non-embedded
platforms). Seriously--RAII alone saves approximately twelve hojillion lines
of code (and saves you from hideous factory-pattern libraries spread hither
and yon, which is also a plus).

The flip side of that coin is that if you don't know what you're doing, you
can blow off your leg, your friend's leg, and the legs of everyone in a
twenty-foot radius.

------
dfox
Why C is vastly superior to C++:

    
    
      $ cat > foo.c
      #include <stdio.h>
      int main(int argc, char**argv){
        puts("hello world");
        return 0;
      }
      ^D
      $ cat > foo.cxx
      #include <iostream>
      int main(int argc, char**argv){
        std::cout << "hello world" << std::endl;
        return 0;
      }
      ^D
      $ time gcc -o hello-c foo.c
      
      real	0m0.039s
      user	0m0.020s
      sys	0m0.012s
      $ time g++ -o hello-c++ foo.cxx
      
      real	0m0.182s
      user	0m0.144s
      sys	0m0.028s

~~~
CountHackulus
Great job measuring initialization time, now how about showing real world
performance differences in actual large programs.

~~~
dfox
It is not about initialization time or even run-time performance, but about
speed of compilation. When any non-trivial program in C++ takes minutes to
build even on high end workstation all benefits that might come from it's
"high level" features are moot.

~~~
toadstone
Are you really saying that the time and energy you save coding and debugging
by using high level features aren't worth a few minutes of compile time? It
won't even be a few minutes except for the first time because of separate
compilation.

~~~
dfox
That is exactly what I'm saying.

Compilation of C++ is really surprisingly slow. Mostly because compilation of
modern C++ code involves parsing tens of megabytes of headers that mostly use
complex to analyze constructs. Fact that C++'s grammar and semantics are
incredibly complex does not help fast compilation either.

Separate compilation does not solve it much, because many simple changes, that
affects only one file in other languages, force you to recompile significant
subset of your codebase.

While you may save time coding I don't believe that debugging C++ code is in
way easier than C code, I think it is quite the reverse. While you mostly
eliminate some problems by using C++ you get whole lot of other C++ specific
problems (static initializers, unexpected effects of overload resolution,
unexpected effects of automatically generated code, weird performance
characteristics...).

Most of this can be worked around, but in that cases you end up using subset
of C++ that could be more flexibly implemented on top of C as few hundred
lines of preprocessor macros and some coding conventions than by it's own
compiler.

~~~
eropple
> Compilation of C++ is really surprisingly slow.

There's definitely something to what you're saying here. Or, rather, maybe
something a few years ago. However, I don't think it really applies so much in
2011. Computers have gotten big and fast to the point where this argument is
pretty meaningless.

Personally, I stopped caring about compilation time when I got a 3.6GHz i7
with eight in-flight threads. I'm OK with feeding the beast on this one--what
I get from C++ is defnitely worth it. (Debugging isn't particularly difficult,
I find - you end up using a subset of C++, but there's no way in hell you
could implement my subset of C++ in C and not hate working with it.)

~~~
rubashov
Concur. C++ compilation speed was legitimately a problem five years ago.
Improved compilers, faster computers, and multi-core compilation have made it
moot.

Often you'll see a C++ basher bring up compilation speed and then in the same
thread advocate python + C as the happy medium, which I find crazy. C++ is so
much higher level than C the need for scripting is often obviated. I've
typically got about 2x SLOC expansion rewriting perl/python as C++, including
stuff like headers, so really not much more code at all, just 100x faster and
a tiny fraction the memory.

The other line you see, including elsewhere on this page right now, is that C
and C++ are the right tool for the job in different domains. I really don't
get this. C++ is straight-up a replacement for C. There is no C program that
wouldn't be shorter and clearer rewritten as C++. The only occasion to not use
C++ is when you don't have compiler support, which is extremely rarely a
concern anymore. Even the lowest level embedded stuff is moving away from C in
favor of C++.

------
KonradKlause
The Dark Side of C++

<http://www.fefe.de/c++/c%2b%2b-talk.pdf>

~~~
mitchi
a very good read.

------
jpr
My reason why C++ is vastly inferior to C:

It's just too goddamn easy to make a mess in C++ without noticing it. In C, if
you make a mess, you will more likely notice it before it's unmanageable.

~~~
thedigitalengel
Can you be more specific?

I have a counter example (assuming I've understood you):

/* C _/

int foo () { FILE _x = fopen("bar"); return 0; }

/* C++ */ int foo () { ifstream in("bar"); return 0; }

~~~
jpr
C assumes that you know the contracts that calling a function implies.
fopen()'s contract requires you to close the file after you are done with it.

------
uriel
I thought everyone knew this, because it creates more and better jobs[1]!

[1] <http://harmful.cat-v.org/software/c++/I_did_it_for_you_all>

~~~
steve-howard
You no doubt know that that "interview" was a complete fabrication. Please
don't present it as fact.

------
leon_
is this an inflammatory troll submission?

~~~
tree_of_item
No, I just see it taken for granted in most places that C++ was a mistake. The
"general wisdom" is that C++ is too complicated for its own good and shouldn't
be used for anything big (the C++ FQA is frequently cited). An article
advocating the opposite position is nice.

------
codegagan
Its Object oriented features !

