
The Dark Side of C++ [pdf] - VeXocide
http://miek.nl/downloads/2010/c++-talk.pdf
======
Silhouette
Please can we stop promoting these language-bashing articles?

Proposing an idea for a new language that avoids a flaw in existing languages
might be interesting.

Actual implementation of such an idea in a working compiler/interpreter that
we can play with might be very interesting.

Just reiterating a bunch of potential dangers in an old language is not
interesting, and it's never going to be. This goes double if the presentation
is subjective and/or incorrect anyway.

------
ramy_d
it's hard to take an article like this seriously - i just want to make 2
highlights. he started using C++ when the STL didn't exist yet. This is
ancient IMO, so his section on ever-changing standard is moot to me. if he
didn't want to maintain the code base, then he should have kept using an older
compiler.

second highlight, errors messages - Debugging is the first skill programmers
(re)learn, so IMO it's a pretty important one. when he says "You get an error
message? You start fudging the code until it compiles." is down right
negligent at best - C++ will tell you at exactly in which file, at which line
and in which function called from which class your error was caused (more than
i can say for other languages) and, i'm sorry, but if you don't know that
compiler errors wrap the code in ' ' then wtf have you been doing since the
dinosaur age when C++ had no stl?

yes, the STL makes compiler errors extra long but to say you need to fudge
with your code to make it work is a spray of FUD to anyone looking to get into
the language.

To close this, everything he said in his "hard to read" could be applied to
any languages with mutability. The code snippets he took were so small or
narrow that no one could be expected to make anything of it. C++ is a strong
typed language, should be read as such and evaluated as such.

~~~
silentbicycle
> To close this, everything he said in his "hard to read" could be applied to
> any languages with mutability.

Really? I _dare_ you to make Python code as hard to read. It has mutability,
too.

Hell, does C code have that same amount of overloading? The worst things C
offers are function pointers and preprocessor hijinks* , while C++ proudly
adds _whole new categories of ways to make code hard to parse or reason
about_. (To say nothing of compile times.)

I learned C++ before the STL, too. For what the STL accomplishes, I'd rather
just use OCaml. C + Lua is also nice - the division emphasizes their strong
points, and each seems to keep each others' complexities in check.

* [http://www.reddit.com/r/programming/comments/b507c/ask_reddi...](http://www.reddit.com/r/programming/comments/b507c/ask_reddit_to_counter_todays_negativity_whats_the/c0l1hxh)

~~~
shin_lao
C has got macros, so it can be very hard to read too.

Generators (<http://docs.python.org/tutorial/classes.html#generators>) in
Python can make code very hard to read as well in "hiding" a lot of complexity
inside the generation.

In other words, such code:

    
    
       r = f(param)
    

can be a lot of different things as well.

The enter/exit clauses hide a lot of code as well, although they should be
used for (de)initialization they can be abused (I've seen it).

Finally, I think you should elaborate more when you say _"for what the STL
accomplishes, I'd rather just use OCaml"_ because I don't understand what it
means and I know both languages (C++ much better, admittedly).

~~~
silentbicycle
I mentioned C macros already, and I don't think Python generators are a good
example - used idiomatically, they usually made code _easier_ to read, and
Python's community imposes a fairly consistent style.

About OCaml - I much prefer its way of doing parametric data structures,
functors, etc.

~~~
ramy_d
so your argument is: my programming language's concepts make it easier to read
as long as you use them correctly, and all of MY friends write the same way
anyway so our language is SUPER easy to read.

breaking news: it's not. the problem with your argument is you're not c++
programmer, and you saw this post on hacker news and decided to come here tell
us how much better whatever language you use is to C++.

you don't seem to consider that this language is the way it is for very
specific reasons. I'm trying to say that this article is VERY poorly written
with very biased opinions and refuses to look at the language as whole.

I'm not saying C++ is the EASIEST language to read, it's not. And his examples
could have passed off as hard to read for ANY LANGAUGE. honestly? bar =
foo(bla); like who the fuck writes like that anyway?

Readability is the trade off the C++ standards committee will always make
because readability will come in the way of the things most important to the
language (C compatibility, speed, high level functionality) but that doesn't
mean you get to take a dump on your keyboard and click the send button.

if you don't understand the issues at stake then don't release you diatribe
into the conversation. C++ isn't python, or C or Ruby nor is it supposed to
be. just accept it.

------
shin_lao
The "hard to read part" is not very honest. You can so similar slides for a
awful lot of languages, I'm not sure I see the point. C macros, for one,
introduce similar issues.

The "C++ makes auditing painful" is just flat out wrong. Any decent IDE
alleviates the trivial ambiguities given as an example (references...).
Auditing isn't done in just reading the code when reaching a certain size,
anyway, so I'm not sure where the author wants to go.

Additionally, a properly written program is consistent, and that's true for
any language. If the program you audit is inconsistent, I can feel your pain,
but don't blame C++ for it.

I also don't understand what "too powerful" means. Power is relative, that C++
is too powerful for many tasks is an obvious statement but saying that it's
just "too powerful full stop" is a bit silly, isn't it?

------
NewSoftzzz
Most of the problems mentioned there don't apply to the regular C++ coder in
his daily life, many of the mentioned problems are even non-existant if you
stick to the encouraged coding styles of modern and real OOP C++.

In practice just the template error messages suck as hell. I'd really like
something nicer there, but in practice you actually survive those messages
without too much wasting of time. You just ignore the error message and rather
look at the line of code mentioned and then you usually find the problem
rather fast by just looking at the line.

rgds, René

~~~
colinb
"encouraged coding styles of modern and real OOP C++"

Where do I go to learn those given that I work in an all C shop? One of the
problems of learning C++ is the sheer profusion of material that's available,
much of it written when the technology looked a lot shinier than it does now.
Would you care to recommend some books or articles on C++ style that have
stood the test of more than one fashion-epoch?

I'm especially worried about the [to my eyes] rather large number of keywords
in C++ and the many exciting ways in which they can interact. I think this is
where advice about useful patterns [sorry] might be most useful.

thanks

c

~~~
jerf
Are you talking about learning OO _to apply in C_? Learning modern C++ OO
won't help much. A little, but not much. A quick google on "object oriented c"
produced a boatload of good-looking sources.

Remember, object orientation is an attribute of a _program_ , not a
_programming language_. A given language may encourage or even force a certain
paradigm, but it's still a property of the resulting program. An "object
oriented" language is simply a language in which it is difficult or impossible
to produce a program that does not have that property. Object-oriented
programming in C is perfectly possible, and often quite desirable. It isn't
quite as slick but it's not terribly hard.

(That said, NewSoftzzz's suggestion of the C++ FAQ Lite is still a good one. I
think it's just plain required reading, personally. Even if you don't program
in C++, it will step you through a lot of scenarios in one very popular OO
paradigm and simply by understanding one paradigm perfectly, it is easier to
understand and use the next. If this seems contradictory to my first
paragraph, blame English. This is theoretically helpful, learning C++ won't
_practically_ help you much in C.)

~~~
colinb
No. I've spent far more of my working life puzzling through OO in C to want to
inflict it on others. But I've also become a fair to middling C programmer,
and the strength I bring to that task has a much to do with knowing how to
build large systems in a comprehensible way from the elements the language
exposes, as it does to a basic knowledge of those elements. I.e. knowing how
to code a case statement isn't the same as building a 50x400 state machine
that's efficient, robust and debuggable.

I suspect the same is true of the skills and knowledge held by an experienced
C++ hacker.

So I suspect that the C++ FAQ, and the Sutter book are just the ticket.

thanks

c

------
loufoque
"Shouldn't throw exceptions in constructors"? Seriously? It's actually
strongly recommended to do so.

Unlike what this article says, it works just fine: \- if you throw from the
constructor-initializer, it destructs all the members and the base classes
that were already initialized, \- if you throw from the constructor body, it
destructs all local variables in scope then all members and base classes.

As for not being able to call virtual functions from base classes, there are
good reasons why it is not allowed.

About bounds checking, GCC does provide a debug mode with operator[] doing
bounds checking.

Local static initialization is thread-safe (see the C++0x standard)

Exception-safety is a serious issue, but solving this problem -- which is
fairly easy, just use RAII -- actually leads to better and safer code.

------
geophile
The author points out that auto_ptr is useless. shared_ptr is broken too. What
do you think this program does?

    
    
        #include <stdlib.h>
        #include <tr1/memory>
        #include <iostream>
    
        using namespace std;
        using namespace std::tr1;
    
        class Node;
        typedef shared_ptr<Node> NodePtr;
    
        class Node
        {
        public:
            int data;
            NodePtr next;
            Node(int data, NodePtr next) : data(data), next(next) {}
            ~Node();
        };
    
        Node::~Node()
        {
            /* cout << "Destroying " << data << endl; */
        }
    
        void shared_ptr_vs_linked_list(int n)
        {
            NodePtr head;
            for (int i = 0; i < n; i++) {
                head.reset(new Node(i, head));
            }
            head.reset();
            cout << "Done " << n << endl;
        }
    
        int main(int argc, const char** argv)
        {
            shared_ptr_vs_linked_list(atoi(argv[1]));
            exit(0);
        }

~~~
kinghajj
I don't see the problem. The nodes of the list are freed from beginning to
end, and then "Done" is printed. What's supposed to be wrong here?

~~~
geophile
Stack overflow for large n.

~~~
kinghajj
Ah, I didn't consider that. A decent optimizing compiler should be able to
remove all the tail calls (G++ did this with your code and -O2), so this
shouldn't be a problem in practice, except maybe for debugging.

------
fs111
you should link to the original source: <http://www.fefe.de/c++/>

------
bad_alloc
If you ever write code like template<class T> struct Loop { Loop<T*>
operator->(); }; Loop<int> i, j = i->hooray; at work you are shown by the
language that you have probably failed to think before you code. A plus in
C++, rather than a downsinde.

If you begin to realize that you need garbage collection you probably failed
while choosing the appropriate language for your project or subproblem.

Same thing here: struct a{typedef int foo;};struct a1:a{};struct a2:a{};
#define X(b,a) struct a##1:b##1,b##2{};struct a##2:b##1,b##2{};
X(a,b)X(b,c)X(c,d)X(d,e)X(e,f)X(f,g)X(g,h)X(h,i)X(i,j)X(j,k)X(k,l)
X(l,m)X(m,n) n1::foo main(){}

Wich sane person would consider writing this a good idea?

------
elmindreda
He makes a valid point; i.e. if you write bad code, your code will be bad.

------
helmut_hed
I like C++ but I think this article is helpful. Having come up the curve in
the last few years, I notice a lot of things I stumbled on are listed... If
this were titled "things to watch out for in C++" it could be a useful guide
for people. Now, though, I just think "yes, that's right" for many of his
points - but it won't stop me from using C++.

------
dimatura
Isn't the different behavior of at() versus operator[] in vectors intentional?
So you use at() if you don't mind a small performance penalty for the sake of
safety, and operator[] otherwise?

------
VBprogrammer
I realise that if you pulled all the warts of any language together into on
document it isn't going to make particularly nice reading. With C++ it is a
bit like a horror story!

------
silentbicycle
The article is called "The Dark _SIDE_ of C++".

(Must not get sucked into C++ bashing thread...)

~~~
VeXocide
Fixed, thank you.

------
huhtenberg
The Dark Side of C++ is that everyone is an opinionated expert. C can be
abused in a similar manner. The output of cpp is notoriously hard to read,
especially if all newlines are removed :) But this is implied and understood
by your average C programmer and therefore it is simply not worth discussing.

