Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dark Side of C++ [pdf]

miek.nl

Post reply on HN
Print view View original

11–20 of 33 posts

Re: The Dark Side of C++ [pdf]

#11

Post by colinb »

NewSoftzzz wrote: post #6

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 t…

"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

Re: The Dark Side of C++ [pdf]

#12

Post by alexk7 »

colinb wrote: post #11
NewSoftzzz wrote: post #6

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 t…

"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 especiall…

The book "C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu is an excellent way to get up to date with modern yet pragmatic C++ style.

I also recommend the "Effective C++" series by Scott Meyers and the "Exceptional C++" series by Herb Sutter.

Re: The Dark Side of C++ [pdf]

#13

Post by geophile »

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

    #include 
    #include 
    #include 

    using namespace std;
    using namespace std::tr1;

    class Node;
    typedef shared_ptr NodePtr;

    class Node
    {
    public:
        int data;
        NodePtr next;
        Node(int data, NodePtr next) : data(data), next(next) {}
        ~Node();
    };

    Node::~Node()
    {
        /* cout

Re: The Dark Side of C++ [pdf]

#15

Post by 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.

Re: The Dark Side of C++ [pdf]

#16

Post by 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.

Re: The Dark Side of C++ [pdf]

#17

Post by kinghajj »

geophile wrote: post #13

The author points out that auto_ptr is useless. shared_ptr is broken too. What do you think this program does? #include #include #include using namespace std; using namespace std::tr1; class Node; typedef shared_ptr NodePtr; class Node { public: int data; NodePtr next; Node(int data, NodePtr next) : data(data), next(next) {} ~Node(); }; Node::~Node() { /* cout

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?

Re: The Dark Side of C++ [pdf]

#18

Post by NewSoftzzz »

colinb wrote: post #11
NewSoftzzz wrote: post #6

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 t…

"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 especiall…

I really do recommend the C++ FAQ book. There is a lite version online: http://www.parashift.com/c++-faq-lite/

Since I've read both the lite online version and the book I strongly encourage you to obtain the book version!

rgds, René

Re: The Dark Side of C++ [pdf]

#19

Post by 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.

Re: The Dark Side of C++ [pdf]

#20

Post by 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?
Post reply on HN