C++ Considered Harmful(esr.ibiblio.org)
esr.ibiblio.org
C++ Considered Harmful
http://esr.ibiblio.org/?p=532
30 comments
Personally I don't agree with ESR. I think C++ is a great language, if used with caution, and I will use it right away in projects where C would normally be used. Specially with useful libraries like STL and Boost being available.
Most plain C projects are reinventing the wheel many times. Linked lists, hashtables, reference counting, OO with function pointers. I'm sure those projects shrink at least 33% in size when they would be using STL or Boost. I've certainly seen that in my own code.
Most plain C projects are reinventing the wheel many times. Linked lists, hashtables, reference counting, OO with function pointers. I'm sure those projects shrink at least 33% in size when they would be using STL or Boost. I've certainly seen that in my own code.
Yep, almost every time I look at good C code I see classes and iterators (written in macros), operators etc. Why not use C++ that has this onboard? C++ is a unique language, it gives you a lot of expressive power with the ability to access the lowest level.
> libraries like STL and Boost being available.
I suspect most of the distaste for C++ is a hang-over from another era. People had some exposure to MFC programming or old compilers with horrible STL support and that formed the popular impression of C++. Modern C++, especially with boost, is a very good language.
I suspect most of the distaste for C++ is a hang-over from another era. People had some exposure to MFC programming or old compilers with horrible STL support and that formed the popular impression of C++. Modern C++, especially with boost, is a very good language.
I was going to say that C++ does at least make the compiler implementor's job easy (as it shifts the burden of complexity onto the application programmer), but then I started to think about what's involved in actually parsing C++, and decided that, hey, maybe it's no picnic for the compiler writers either...
C++ is probably the hardest widely used language to parse. See the "FQL" for more:
http://yosefk.com/c++fqa/defective.html#defect-2
(Note: I use and like C++ for a lot of things, but there is a lot of valid criticism of it and the FQL rants are at least well-informed.)
http://yosefk.com/c++fqa/defective.html#defect-2
(Note: I use and like C++ for a lot of things, but there is a lot of valid criticism of it and the FQL rants are at least well-informed.)
I do consider C++ a bad language. The syntax is a MESS, it's quite lacking on the OO front, and the language/STL misses some quite important components (e.g. concurrency, networking). And having an actual ABI would help too.
However, it's still generally my language of choice, and not only because it's the language I know most. It has the flexibility of C while providing some OO capabilities and the STL. And there is the widespread availability too (although that's not really C++'s honour but GCC's).
One could also argue that C++ software is easier to deploy, as it needs no VMs or interpreters, but it's quite a moot point because every moderately sized application will have 3rd party dependencies to provide everything the STL is lacking.
Also, the RAII idiom is perhaps my favorite pattern, and I'm yet to see a language that has RAII support as strong as C++ has. (Although I do plan to have further investigations about Python 3k/2.5's 'with' statement, it seems to be a good contender) I rely heavily on RAII while coding/desinging, this makes coding in Java very sour for me. And Ruby's block idiom, while it's really lovely and comes very handy in many cases, it ain't no RAII.
Like it or not, while it's slowly fading away, C++ will still be around for a while. I don't really see KDE rewritten in any other language any time soon.
However, it's still generally my language of choice, and not only because it's the language I know most. It has the flexibility of C while providing some OO capabilities and the STL. And there is the widespread availability too (although that's not really C++'s honour but GCC's).
One could also argue that C++ software is easier to deploy, as it needs no VMs or interpreters, but it's quite a moot point because every moderately sized application will have 3rd party dependencies to provide everything the STL is lacking.
Also, the RAII idiom is perhaps my favorite pattern, and I'm yet to see a language that has RAII support as strong as C++ has. (Although I do plan to have further investigations about Python 3k/2.5's 'with' statement, it seems to be a good contender) I rely heavily on RAII while coding/desinging, this makes coding in Java very sour for me. And Ruby's block idiom, while it's really lovely and comes very handy in many cases, it ain't no RAII.
Like it or not, while it's slowly fading away, C++ will still be around for a while. I don't really see KDE rewritten in any other language any time soon.
Much of the reason that RAII is such a big deal for C++ is that C++ doesn't help manage resources. The fact that one can free in destructors and that destructors are called automatically in some circumstances is important only if you need to free. That's simply not an issue for many languages.
Yes, there are other resources to manage. Python's with and Common Lisp's unwind-protect are both good for open file handles and the like. unwind-protect is better than with and with is better than constructor/destructor because constructor/destructor and to a lesser extent with require too many contortions to use.
Yes, there are other resources to manage. Python's with and Common Lisp's unwind-protect are both good for open file handles and the like. unwind-protect is better than with and with is better than constructor/destructor because constructor/destructor and to a lesser extent with require too many contortions to use.
concurrency, networking - boost has both
I'm personally tired of "x Considered Harmful" articles. Not only are they terribly cliche, but most of them are about complex, highly debated issues and do not really prove their point.
I think this comment sums it pretty nicely:
---> "So, to answer your question about how many wizards C++ has ruined, I can argue that I never bothered to go further in programming due to feeling utterly lost with C++ and Perl." ;-))
However, one comment is worth discussion: "There is no reason to use C++ for new projects."
Do you agree with this? What is a better choice then for developing standalone apps or libraries where speed is critical? It's funny to watch how some people bash c++, and then, when we need to develop some critical app, like javascript engine, suddenly the choice is again C++. ;-)
---> "So, to answer your question about how many wizards C++ has ruined, I can argue that I never bothered to go further in programming due to feeling utterly lost with C++ and Perl." ;-))
However, one comment is worth discussion: "There is no reason to use C++ for new projects."
Do you agree with this? What is a better choice then for developing standalone apps or libraries where speed is critical? It's funny to watch how some people bash c++, and then, when we need to develop some critical app, like javascript engine, suddenly the choice is again C++. ;-)
What's wrong with C? Essentially all the speed-critical code on your system (think: the kernel, stuff like openssl, libpng/libjpg, audio & video codecs, MySQL, PostgreSQL, ruby, perl, python, php, apache, nginx, memcached, ...) is written in C, and it works great.
There's a strange disease among modern application programmers where they seem not to be able to "see C" even when it's driving the very engines of their success. If you just look a tiny bit more deeply, you'll discover that it's not nearly as hard as you think it is.
There's a strange disease among modern application programmers where they seem not to be able to "see C" even when it's driving the very engines of their success. If you just look a tiny bit more deeply, you'll discover that it's not nearly as hard as you think it is.
> What's wrong with C?
Mostly ignorance of the rant authors :) In fact, one way to view C++ is as a beefed up C. Specifically a moderate use of the following simplifies life quite a bit and retains almost all benefits of C -
* templates instead of macros
* pure classes for the callbacks instead of function pointers with void pointer contexts
* standard inline functions
* STL containers (not perfect from memory utilization and perspective, but typically are ok)
Exceptions can also come handy, but these require a lot of moderation if used in a fastpath code.
Mostly ignorance of the rant authors :) In fact, one way to view C++ is as a beefed up C. Specifically a moderate use of the following simplifies life quite a bit and retains almost all benefits of C -
* templates instead of macros
* pure classes for the callbacks instead of function pointers with void pointer contexts
* standard inline functions
* STL containers (not perfect from memory utilization and perspective, but typically are ok)
Exceptions can also come handy, but these require a lot of moderation if used in a fastpath code.
What's wrong with C? Essentially all the speed-critical code on your system (think: the kernel, stuff like openssl, libpng/libjpg, audio & video codecs, MySQL, PostgreSQL, ruby, perl, python, php, apache, nginx, memcached, ...) is written in C, and it works great.
Everything you've mentioned has crashed on me from time to time due to memory allocation errors. C is not a great langauge. It is assembly langauge with sugary syntax for loops, and a preprocessor that whines if you try to add a double and an integer.
The advantage is speed. The disadvantage is that programs written in C are only correct due to luck.
Oh, and the reason all of the above are written in C is because there is a common misconception that you have to write "system software" in C. You don't but people think you do. So they do.
Everything you've mentioned has crashed on me from time to time due to memory allocation errors. C is not a great langauge. It is assembly langauge with sugary syntax for loops, and a preprocessor that whines if you try to add a double and an integer.
The advantage is speed. The disadvantage is that programs written in C are only correct due to luck.
Oh, and the reason all of the above are written in C is because there is a common misconception that you have to write "system software" in C. You don't but people think you do. So they do.
I'm not following. The discussion is about C++, which shares the same heap management as C, so I don't see what you are trying to say here.
And I'll be frank: the hubris in your discounting the programming skills and choices of all of those working, mature, robust and very successful projects is just absolutely stunning. Have you ever delivered anything of comparable quality? Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code. I'll submit that these projects are written in C because their rather talented authors see something in that environment that you don't. And that the fact that you don't see value in an environment that is undeniably producing valuable software says more about you than it does about them.
Seriously dude, you gotta check that attitude.
And I'll be frank: the hubris in your discounting the programming skills and choices of all of those working, mature, robust and very successful projects is just absolutely stunning. Have you ever delivered anything of comparable quality? Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code. I'll submit that these projects are written in C because their rather talented authors see something in that environment that you don't. And that the fact that you don't see value in an environment that is undeniably producing valuable software says more about you than it does about them.
Seriously dude, you gotta check that attitude.
I'm not following. The discussion is about C++, which shares the same heap management as C, so I don't see what you are trying to say here.
You were the one who brought up C. But basically, all languages that require manual memory management fall into the category of "you probably shouldn't use them". Memory management is too hard for people to get right. Computers are much better at that tedious task. (As an aside, it is interesting that it's easier to write a generic memory manager than to remember to do it right every time yourself. Programming is an interesting art.)
Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code.
Honestly, this is a bad example. When Python and Perl were started, there was no other option for writing a language that would run on UNIX. UNIX software was written in either C or shell. Now that Perl and Python exist, they are much better choices than C for almost any class of problem. That's why they were written. If Guido and Larry actually wanted to use C for everything, they wouldn't have needed to write their own languages.
BTW, the Perl6 implementation written with Haskell came together in about a weekend, while the C implementation is about as complete after 5-or-so years. C is a pain.
Finally, I find it condescending that you want to throw away the last 40 years of programming language research because UNIX is written in C. Remember the Lisp machines? It's a shame that UNIX lost out to them, because it was much easier to write software (and libraries) in Lisp than in C. Oh well, at least we have emacs.
C has its purpose, but its purpose is not for writing programming languages, web servers, or desktop applications.
You were the one who brought up C. But basically, all languages that require manual memory management fall into the category of "you probably shouldn't use them". Memory management is too hard for people to get right. Computers are much better at that tedious task. (As an aside, it is interesting that it's easier to write a generic memory manager than to remember to do it right every time yourself. Programming is an interesting art.)
Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code.
Honestly, this is a bad example. When Python and Perl were started, there was no other option for writing a language that would run on UNIX. UNIX software was written in either C or shell. Now that Perl and Python exist, they are much better choices than C for almost any class of problem. That's why they were written. If Guido and Larry actually wanted to use C for everything, they wouldn't have needed to write their own languages.
BTW, the Perl6 implementation written with Haskell came together in about a weekend, while the C implementation is about as complete after 5-or-so years. C is a pain.
Finally, I find it condescending that you want to throw away the last 40 years of programming language research because UNIX is written in C. Remember the Lisp machines? It's a shame that UNIX lost out to them, because it was much easier to write software (and libraries) in Lisp than in C. Oh well, at least we have emacs.
C has its purpose, but its purpose is not for writing programming languages, web servers, or desktop applications.
OCaml is quick to write and produces executables with great performance.
Ok, but if you would be a project manager responsible for developing and delivering software product, would you choose non-mainstream language for the project?
OCaml might be better in academic sense as the language itself, but now I talk about commercial product...so you would need to take all factors of software development into consideration - like how you will find future developers if you expand, what the support will be, etc. etc.
OCaml might be better in academic sense as the language itself, but now I talk about commercial product...so you would need to take all factors of software development into consideration - like how you will find future developers if you expand, what the support will be, etc. etc.
Adding a bunch of "what ifs" to justify your choice of language is not a good argument technique.
"What if your manager is paid by Sun to only advocate Java?" There's no way to argue that, but it doesn't matter, because it's irrelevant.
Pick the langauge you want to use.
"What if your manager is paid by Sun to only advocate Java?" There's no way to argue that, but it doesn't matter, because it's irrelevant.
Pick the langauge you want to use.
>> Pick the langauge you want to use.
I can't, because I am just one worker and the language is choosen by the top product manager. That's not a complaint, my point was that you usually can not choose a language you want to use in professional setting. You can do so for your hobby project.
I can't, because I am just one worker and the language is choosen by the top product manager. That's not a complaint, my point was that you usually can not choose a language you want to use in professional setting. You can do so for your hobby project.
Leave and start a competing company that Does Things Better because you spend your time solving problems, not debugging pointers. :)
I don't know why C++ is much hated when all the big applications at amazon, google, microsoft, adobe, apple are written in C++. I think it's the best practical language for good scalable applications.
That's debatable. It is, however, the most widely known language (besides maybe java?) that you can write the types of applications that C++ is used for in.
I don't like C++, but ESR's reasoning here is faulty. C++ was not meant to be elegant; it was meant to run quickly and have some OO. It succeeds at both of those.
The hard part is writing and compiling it. The syntax is bad, the language features are easy to misuse, and the compilers are slow and don't give good error messages.
But the main reason to hate C++ is because allocating your own memory and figuring out what type variables have is a job for the computer, not for the programmer.
The hard part is writing and compiling it. The syntax is bad, the language features are easy to misuse, and the compilers are slow and don't give good error messages.
But the main reason to hate C++ is because allocating your own memory and figuring out what type variables have is a job for the computer, not for the programmer.
C++ is the "great white whale" of programming languages? It is not. It is the manatee of programming languages, trivially located and dispatched, though more often by accident than by intent, because who gives a shit?
If you want proper C++ schlaging, here it is, done right:
C++ Frequently Questioned Answers: http://yosefk.com/c++fqa/
We now returned to your regularly scheduled uninformed language rants.