

Why I No Longer Like or Use C++ - muriithi
http://prophipsi.blogspot.com/2008/03/why-i-no-longer-like-or-use-c.html

======
scott_s
C++ is a systems programming language first, and an application programming
language second. There was a time when there was little difference between the
two areas.

System resources are not as precious as they used to be, so the distinction
has become more apparent. Hence, people who use C++ for non-systems
programming encounter friction when performance goals are at odds with
productivity goals. They then move to languages which take the opposite
approach and sacrifice performance for productivity.

I use and like using C++. Yet I don't see any reason to argue when he says C++
is not for him any longer - he's probably right. I think the domain where C++
is appropriate has shrunk and continue to do so, and that's fine.

(For the record, rvalue references are a means to eliminate copying objects.
This is, indeed, a performance optimization that most people don't care
about.)

~~~
comatose_kid
Do you have any examples where C++ has been used as a systems programming
language? I thought C held that role.

~~~
mellampudi
Symbian os is coded in c++

~~~
huhtenberg
Another example is (was ?) NuMega's DriverStudio framework for developing
Windows drivers in C++. Both examples are more of an exception rather than a
rule though.

Here's a lovely discussion from few years back:
[http://developers.slashdot.org/article.pl?sid=04/10/27/21102...](http://developers.slashdot.org/article.pl?sid=04/10/27/2110228)

------
huhtenberg
First comment on the article's own page pretty much nails it. C++ is flexible
enough to be used as beefed up C - templates instead of macros, abstract
classes and 'this' instead of callbacks and their arguments, operator
overloading to produce more compact the code, etc. Noone is _forced_ to use
multiple inheritance, virtual base classes, template specialization and other
++ wonders.

The guy also claims that "every single aspect of C++ being designed around
higher performance instead of my productivity". This is false. The fact that
it allows writing high-performance code does not mean it was one of the
primary design goals. It simply was not, this aspect of the language was
inherited from C .. which is one of the languages the author declares to be
"going back" to. Kind of ironic if you think about it.

<http://www.dmk.com/c++/stroustrup_1986_10.html>

~~~
scott_s
Err, if you read Stroustrup's Design & Evolution of C++, performance clearly
was one of the primary design goals. Goals 2 and 3 in the statement you linked
to spell that out. If a feature could not be implemented without effecting the
efficiency of programs that did not use it, the feature was rejected. One of
the points that Stroustrup stresses in D&E is that he wanted no languages
below C++.

There are many features that do have a runtime or space cost, but you only pay
for it if you use it. And I think that in many cases, what you end up
implementing yourself would pay the same performance costs, if not more.

~~~
huhtenberg
You didn't quite follow what I said or I phrased it badly. C++ performance
requirements are inherited from "be like C" requirement. So when the guy says
that he's going back to C, because C++ is "all about performance and not
usability", it just does not make any sense.

~~~
scott_s
Sorry, I understand what you meant now.

------
ghiotion
I used VC++ in my first job, using Microsoft's ATL to extend the functionality
of an ActiveX based Web app from Mercury Interactive (TestDirector, for those
that are interested). It was utterly horrible, but I wasn't aware of it at the
time.

I basically agree with the author of the post. I've never understood the use
of virtual and template classes. However, I like what Anonymous says in the
comments:

>Here's the secret to good use of C++: Never use STL. Never use any template
libraries. Furthermore, never use templates.

>Pretend that it's C, with some nifty object-oriented features and operator
overloading. Nothing more.

~~~
wheels
STL does blow. Templates are fine if used sparingly (i.e. non-STL container
classes). Virtuals shouldn't be optional (a la Java). I'd add to the list that
references in C++ are silliness (const reference usage should be a detail
handled by the compiler automatically, non-const references just lead to
ambiguous APIs).

The problem really seems to be that there are still some niches where you need
something with relatively fine grained control and raw horsepower of C++, but
there's not been anything to come along to fill that niche.

A simplified C++ standard would be a step in the right direction.
Unfortunately it seems that the standard is moving in the opposite direction.

For what it's worth, I find programming with Qt pretty close to "C++ as it
should be".

~~~
scott_s
I make extensive use of the STL, so I'm curious to hear why you don't like it.

~~~
wheels
I use it on a daily basis, so my ranting is coming from a different angle than
the author's. The main problems that I see about the STL is that I find it
more of a demo library for showing off how far you can push the generic
programming metaphor than a pragmatically designed toolkit.

Here are a few points:

\- Heavy template usage makes debugging hard. The Intel compiler does the best
job I've seen of reporting sane errors, but it's still ugly.

\- Heavy template usage makes the symbol count and binary size explode. Bigger
binaries mean more cache pressure, so this slows things down, makes for bigger
downloads, etc. (For a project at work recently I had to refactor some of our
template based code to be OO instead as heavy template usage and associated
expansion was quite literally adding 20 MB to our application's size.)

\- The API is fugly.

~~~
tx
I can see why you're saying what you're saying, but I didn't find debugging
particularly hard, and binary size explosion is probably your particular
compiler's problem: MSVC 7.1 works very nice with templates, generating code
only when absolutely needed, and sharing generated method/function instances
across multiple template instantiations when types allow.

Moreover, STL is beautiful. It was originally designed for Smalltalk if I
remember correctly, and it's "ugliness" is nothing more than a bad
implementation. Separating alogrithms away from the data types they operate on
is a novel idea. Granted, you get it for free in dynamic languages, but STL
goes as far as you can get in a rigid world of stone types.

I have been facsinated by C++, by its ugliness, its sheer size, hidden powers
and fast code it generates. My interest in it has faded away as CPUs got
faster.

In my opinion the biggest issue with C++ is the lack of any kind of modules,
and the author of the original post correctly recognizes that. Those endless
includes multiplied by need for templates, produce ridiculous build times and
make it impossible to hide implementation details (everythin g is still
exposed via hpp-files).

------
aswanson
I use C++ for image processing. Would I like to use Ruby? Of course. Do I know
that if I do so I cannot process 30 frames a second? Yes. You take what
liberties the problem at hand extends to you and save the dogma for the
preisthood.

