The Dark Side of C++ [pdf] (miek.nl)

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

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é

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?

    #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);
    }

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.

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.

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.

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?