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

The Dark Side of C++ (2007) [pdf]

fefe.de

Post reply on HN
Print view View original

31–40 of 55 posts

Re: The Dark Side of C++ (2007) [pdf]

#31

Post by jrajav »

karterk wrote: post #17

Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help. The point about operator overloading is accepted, but this is not too different from what happens with metaprogramming in Ruby or say macros in lisp. Even python has some quirks. See: http://stackoverflow.com/questions/1132941/least-astoni…

> Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help.

Then why must variables have static types?

Re: The Dark Side of C++ (2007) [pdf]

#32

Post by drucken »

nikic wrote: post #22
epidemian wrote: post #20

Earlier quoted context omitted.

Exactly. One valid criticism could be that getting exceptions right in C++ can be quite a challenge; i remember that at one point i was very into the language and was blown away by reading Exceptional C++ ( really recommended for any C++ programmer), i was like re-discovering the whole language altogether.

Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time). E.g. the example with file open + close in the presentation is laughable. Every C++ programmer knows that this is something that should be done with RAII. I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you r…

Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time).

... and the remaining people realise that use of exceptions in C++,

1. almost always creates a trade-off in performance for strong-exception safety guarantees

2. requires special and strong control of side effects throughout the code base, even when there is minimal benefit

3. increases compile times and resource pressure

4. encourages less knowledgeable developers to inappropriately throw exceptions or make poor attempts to recover from them

5. contain some of the least portable platform semantics and handling.

C++ exceptions contain far greater costs and consequences than many programmers realise. For anything other than testing frameworks, it is debatable that they are worth any benefit at all compared to the alternatives.

Re: The Dark Side of C++ (2007) [pdf]

#33

Post by tragomaskhalos »

dakimov wrote: post #19

I agree. C++ is a poorly designed language with a lot of "bugs" in it. Languages do not pass the usual development cycle that includes collection of requirements, beta-testing and bug fixing. C++ have some obviously stupid design decisions that apparently will never be fixed. Strangely or not, people tend to approach languages religiously rather than rationally. Languages are like holy scripts that are written by one…

C++ is not a "poorly designed language", it is a language with a number of difficult corners imposed by legacy compatibility with (originally) C, and later with its own multiple decades of use. Features that have serendipitously been free of such constraints are generally extremely well designed. It is of course possible, easy even, to design a language ex novo that has no such legacy baggage, yet none is remotely as compelling as C++ for a wide swathe of tasks, more eloquent testimony to the quality of C++ than any amount of Internet squabbling.

Re: The Dark Side of C++ (2007) [pdf]

#36

Post by rspring »

Yea, let's write all of our higher level object juggling in C++! Such a nice language, isn't it? And there aren't much alternatives either, right? Let's be honest: if you find yourself complaining about C++ syntax and error messages while coding your higher level logic, chances are you either like the pain or you have lived under a rock for the last 15 years. In the latter case, go open your browser and type "Python" (or "JNI" or "Javascript" for that matter).

Re: The Dark Side of C++ (2007) [pdf]

#37

Post by npsimons »

Some valid points, but I was hoping for more meat, maybe references to what I call "dark corners" of C++. Take, for instance, writing a simple logging class that can log to multiple places and can be used in place of std::cout. The solution I initially came up with is a variation on http://wordaligned.org/articles/cpp-streambufs, with some manipulator magic thrown in to adjust severity level. Ah, but that's not good enough, you have to pull some interesting gymnastics to ensure order of IOStream initialization: http://accu.org/index.php/journals/264. And after all that, I'm still not sure it works, as looking at the data structures in a debugger looks like garbage (guess why I'm in the debugger in the first place).

All that being said, I still love C++. I'm glad I know it as well as I do so that I can (usually) avoid problems, but even then I run into compiler (or build!) dependent problems that shouldn't be happening. C++ has problems, and we need to address them. I'm happy to say that even though I am stuck with old compilers that have inscrutable template error messages, time moves on and I am aware of this problem being fixed in newer versions of compilers.

Re: The Dark Side of C++ (2007) [pdf]

#38

Post by gtani »

Haven't had one of these anti-C++ threads/rants in a while, prbably not much new here

https://news.ycombinator.com/item?id=4969372

http://news.ycombinator.com/item?id=4539251

http://news.ycombinator.com/item?id=3712292

______________

this mechanization of the lang spec in Coq looks interestng

http://hal.inria.fr/hal-00674663/en

Re: The Dark Side of C++ (2007) [pdf]

#40

Post by gcv »

Some valid points, some outdated ones. I have found C++11 surprisingly enjoyable. Real lambdas, templates, and unique_ptr/shared_ptr have let me write exceedingly Lispy and highly-readable code. With great performance characteristics.

Minimizing the use of OOP helps avoid the language's sharp corners. With C++11, I highly recommend abandoning the "C with classes" style.

Post reply on HN