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

21–30 of 55 posts

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

#21

Post by mrich »

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…

You cannot determine the "best language" (for a given project) from a computer science aspect only. In the real world things like availability of programmers, existing code/interfacing with libraries, support of different platforms etc. play a much larger role.

D may be superior to C++, but if you have to build a firmware in one year and you will need 20 developers you cannot use this language since you cannot hire that many experienced developers and the D compiler may not even target your platform.

Even luck and being in the right spot at the right time by coincidence play a large part. Consider Javascript, which was never designed to do all the stuff people use it for nowadays. But for all its flaws it solved people's problems at the right time and therefore got popular. It was the same with C and C++.

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

#22

Post by nikic »

epidemian wrote: post #20
alexchamberlain wrote: post #7

Earlier quoted context omitted.

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.

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 remembering to add a close call on every possible exit-path.

Also one should point out that C++11 has unique_ptr and shared_ptr which in many cases remove the need for the programmer to manage things by himself.

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

#23

Post by tawgx »

C++ is a really tough language, especially when compared to more modern ones (Python, Ruby, Scala,..). There are two things which I've always found frustrating about the language. The first is that there are so many arcane elements to it that even highly experienced devs can make mem alloc mistakes that will cause the app to SIGSEGV down the road, and it's pure misery to root these out. The 2nd has to do with that it's not really cross platform in that it can be super hard to move code between win and nix, something that languages like Java and Python have all but made transparent. I know there's a lot of work done on C++ the last few years, but nowadays while we still write C++ for some parts of our app there's almost always a legacy part to it.

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

#24

Post by betterunix »

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…

"I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path."

Unless closing the handle causes an exception to be thrown. Either you never see the exception or your program aborts, and neither one is particularly good if you want to write reliable code.

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

#25

Post by PommeDeTerre »

mrich wrote: post #15

While 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 com…

While I agree that ambiguous code can be a problem, I think it's much less of an issue in C++ than it is in dynamic languages like JavaScript and Ruby.

It's not at all unusual, although it is very unfortunate, to run into JavaScript or Ruby code where monkey patching will change the behavior of large sections of code several different times throughout the runtime of an app. This is especially true when the standard library is affected. Debugging situations like this can become very tedious, very quickly.

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

#27

Post by JoeAltmaier »

mrich wrote: post #15

While 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 com…

To be fair, template error messages are still a black art. They can take half a page. Reminds me of the old CFront days when C++ compiler was a front-end for another compiler. Templates are not very well integrated still.

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

#28

Post by mrich »

JoeAltmaier wrote: post #27
mrich wrote: post #15

While 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 com…

To be fair, template error messages are still a black art. They can take half a page. Reminds me of the old CFront days when C++ compiler was a front-end for another compiler. Templates are not very well integrated still.

clang has solved this problem mostly with their template type diffing. gcc has also improved in that area.

http://clang.llvm.org/diagnostics.html

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

#29

Post by zanny »

Devid2013 wrote: post #12

Another 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...

I was exploring some features of Android this week and every other line I kept sticking comments in like "gosh, if only java had first class functions / closures / operator overloading / namespaces / global primitives that aren't hackneyed"

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

#30

Post by zxcdw »

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…

You call out for rationality and claim that C# fixes C++'s problems? A language which requires a heavy runtime, really?
Post reply on HN