The author also runs a blog written in C (blog.fefe.de)
Somehow I'm not surprised.
The Dark Side of C++ (2007) [pdf]
11–20 of 55 posts
Re: The Dark Side of C++ (2007) [pdf]
#12Another bad article against C++.
There is no perfect language and C++ is not perfect too.
But using some other langauges I fell offten like be prisoner...
Re: The Dark Side of C++ (2007) [pdf]
#13The author also runs a blog written in C (blog.fefe.de)
And written an own Libc:
http://www.fefe.de/dietlibc/
Re: The Dark Side of C++ (2007) [pdf]
#14full of crap. It sounds like when an office clerk in a publisher house demands abandoning latin words, puns, ironies figures of speech etc. because he is too dumb to use them properly. There are poets and there are mba-style bullshit writers. Great C++ code can read as beautifully as poems in style and elegance (c.f. Elements of Programming by Stepanov).
Re: The Dark Side of C++ (2007) [pdf]
#15While some points may be incorrect and some outdated in this 2007 presentation there are valid points. Especially it is true that the behavior of a line of code in C++ cannot easily be inferred from it alone, which can quickly become a problem as a code base grows in size and there is no common coding standard. A coding standard and automatic tools to enforce it (think clang-based compiler plugins that run before commit) can solve such problems and make C++ still one the best languages out there for high-performance programs, while guaranteeing good maintainability of the code.
There is C++ code out there which reads beautifully and is correct, you just have to work a little harder than in other languages. When you need the performance and control then it is worth the additional effort.
Re: The Dark Side of C++ (2007) [pdf]
#16"There is no dark side of the moon really. Matter of fact it's all dark."
Re: The Dark Side of C++ (2007) [pdf]
#17Hmm, 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-astonishmen...
Re: The Dark Side of C++ (2007) [pdf]
#18full of crap. It sounds like when an office clerk in a publisher house demands abandoning latin words, puns, ironies figures of speech etc. because he is too dumb to use them properly. There are poets and there are mba-style bullshit writers. Great C++ code can read as beautifully as poems in style and elegance (c.f. Elements of Programming by Stepanov).
Well, the compiler error messages (few examples given by the author of the article) also looks like poetic phrases to you :D
Re: The Dark Side of C++ (2007) [pdf]
#19I 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 or a few people that are perceived like gods, and there is no proper critism or improvement following the development of a language.
Hence what we have today.
One of the most popular languages is full of stupid design mistakes that will never be fixed, they rather die with the language.
Actually, an example of a language that fixes many of the C++ problems is C#. But it inherently cannot be a replacement of C++.
Again, people are not rationally thinking creatures.
And to all who are not rationally thinking, I just say: fuck you.
Re: The Dark Side of C++ (2007) [pdf]
#20This presentation is from 2007. It's outdated and full of errors. I'll refer to the comments at /r/programming http://www.reddit.com/r/programming/comments/193o4p/the_dark...
I call BS on most of the presentation. For example, throwing exceptions from a constructor is not only acceptable, it's the only way to prevent construction.
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.