Why I No Longer Like or Use C++(prophipsi.blogspot.com)
prophipsi.blogspot.com
Why I No Longer Like or Use C++
http://prophipsi.blogspot.com/2008/03/why-i-no-longer-like-or-use-c.html
4 comments
Do you have any examples where C++ has been used as a systems programming language? I thought C held that role.
oddly enough, a good chunk of OS/400 was written in C++ - http://portal.acm.org/citation.cfm?id=226239.226253&coll...
Much of the examples on Stroustrup's page qualify as systems code: http://www.research.att.com/~bs/applications.html.
A high profile, recent example is Google's MapReduce: http://labs.google.com/papers/mapreduce.html.
A high profile, recent example is Google's MapReduce: http://labs.google.com/papers/mapreduce.html.
Actually, they don't. Neither the MapReduce nor nearly all items on Stroustrup's list fall under conventional definition of the "system programming". It is an established term that does not mean programming of a system. It is rather a synonym of the "OS development".
http://en.wikipedia.org/wiki/Systems_programming
http://en.wikipedia.org/wiki/Systems_programming
I include it to mean support software that sits between the OS and applications, like a runtime system or a memory allocator. Much of that code (and MapReduce) qualify.
Symbian os is coded in c++
Another example is (was ?) NuMega's DriverStudio framework for developing Windows drivers in C++. Both examples are more of an exception rather than a rule though.
Here's a lovely discussion from few years back: http://developers.slashdot.org/article.pl?sid=04/10/27/21102...
Here's a lovely discussion from few years back: http://developers.slashdot.org/article.pl?sid=04/10/27/21102...
I didn't know that - thanks.
BeOS was C++
not the kernel! it was very strictly C-only, no C++ allowed. the application frameworks were in C++, but that's not really the "operating system."
and i'm in a position to know. i actually worked at Be for awhile.
and i'm in a position to know. i actually worked at Be for awhile.
First comment on the article's own page pretty much nails it. C++ is flexible enough to be used as beefed up C - templates instead of macros, abstract classes and 'this' instead of callbacks and their arguments, operator overloading to produce more compact the code, etc. Noone is forced to use multiple inheritance, virtual base classes, template specialization and other ++ wonders.
The guy also claims that "every single aspect of C++ being designed around higher performance instead of my productivity". This is false. The fact that it allows writing high-performance code does not mean it was one of the primary design goals. It simply was not, this aspect of the language was inherited from C .. which is one of the languages the author declares to be "going back" to. Kind of ironic if you think about it.
http://www.dmk.com/c++/stroustrup_1986_10.html
The guy also claims that "every single aspect of C++ being designed around higher performance instead of my productivity". This is false. The fact that it allows writing high-performance code does not mean it was one of the primary design goals. It simply was not, this aspect of the language was inherited from C .. which is one of the languages the author declares to be "going back" to. Kind of ironic if you think about it.
http://www.dmk.com/c++/stroustrup_1986_10.html
Err, if you read Stroustrup's Design & Evolution of C++, performance clearly was one of the primary design goals. Goals 2 and 3 in the statement you linked to spell that out. If a feature could not be implemented without effecting the efficiency of programs that did not use it, the feature was rejected. One of the points that Stroustrup stresses in D&E is that he wanted no languages below C++.
There are many features that do have a runtime or space cost, but you only pay for it if you use it. And I think that in many cases, what you end up implementing yourself would pay the same performance costs, if not more.
There are many features that do have a runtime or space cost, but you only pay for it if you use it. And I think that in many cases, what you end up implementing yourself would pay the same performance costs, if not more.
You didn't quite follow what I said or I phrased it badly. C++ performance requirements are inherited from "be like C" requirement. So when the guy says that he's going back to C, because C++ is "all about performance and not usability", it just does not make any sense.
Sorry, I understand what you meant now.
I used VC++ in my first job, using Microsoft's ATL to extend the functionality of an ActiveX based Web app from Mercury Interactive (TestDirector, for those that are interested). It was utterly horrible, but I wasn't aware of it at the time.
I basically agree with the author of the post. I've never understood the use of virtual and template classes. However, I like what Anonymous says in the comments:
>Here's the secret to good use of C++: Never use STL. Never use any template libraries. Furthermore, never use templates.
>Pretend that it's C, with some nifty object-oriented features and operator overloading. Nothing more.
I basically agree with the author of the post. I've never understood the use of virtual and template classes. However, I like what Anonymous says in the comments:
>Here's the secret to good use of C++: Never use STL. Never use any template libraries. Furthermore, never use templates.
>Pretend that it's C, with some nifty object-oriented features and operator overloading. Nothing more.
STL does blow. Templates are fine if used sparingly (i.e. non-STL container classes). Virtuals shouldn't be optional (a la Java). I'd add to the list that references in C++ are silliness (const reference usage should be a detail handled by the compiler automatically, non-const references just lead to ambiguous APIs).
The problem really seems to be that there are still some niches where you need something with relatively fine grained control and raw horsepower of C++, but there's not been anything to come along to fill that niche.
A simplified C++ standard would be a step in the right direction. Unfortunately it seems that the standard is moving in the opposite direction.
For what it's worth, I find programming with Qt pretty close to "C++ as it should be".
The problem really seems to be that there are still some niches where you need something with relatively fine grained control and raw horsepower of C++, but there's not been anything to come along to fill that niche.
A simplified C++ standard would be a step in the right direction. Unfortunately it seems that the standard is moving in the opposite direction.
For what it's worth, I find programming with Qt pretty close to "C++ as it should be".
I make extensive use of the STL, so I'm curious to hear why you don't like it.
I use it on a daily basis, so my ranting is coming from a different angle than the author's. The main problems that I see about the STL is that I find it more of a demo library for showing off how far you can push the generic programming metaphor than a pragmatically designed toolkit.
Here are a few points:
- Heavy template usage makes debugging hard. The Intel compiler does the best job I've seen of reporting sane errors, but it's still ugly.
- Heavy template usage makes the symbol count and binary size explode. Bigger binaries mean more cache pressure, so this slows things down, makes for bigger downloads, etc. (For a project at work recently I had to refactor some of our template based code to be OO instead as heavy template usage and associated expansion was quite literally adding 20 MB to our application's size.)
- The API is fugly.
Here are a few points:
- Heavy template usage makes debugging hard. The Intel compiler does the best job I've seen of reporting sane errors, but it's still ugly.
- Heavy template usage makes the symbol count and binary size explode. Bigger binaries mean more cache pressure, so this slows things down, makes for bigger downloads, etc. (For a project at work recently I had to refactor some of our template based code to be OO instead as heavy template usage and associated expansion was quite literally adding 20 MB to our application's size.)
- The API is fugly.
I can see why you're saying what you're saying, but I didn't find debugging particularly hard, and binary size explosion is probably your particular compiler's problem: MSVC 7.1 works very nice with templates, generating code only when absolutely needed, and sharing generated method/function instances across multiple template instantiations when types allow.
Moreover, STL is beautiful. It was originally designed for Smalltalk if I remember correctly, and it's "ugliness" is nothing more than a bad implementation. Separating alogrithms away from the data types they operate on is a novel idea. Granted, you get it for free in dynamic languages, but STL goes as far as you can get in a rigid world of stone types.
I have been facsinated by C++, by its ugliness, its sheer size, hidden powers and fast code it generates. My interest in it has faded away as CPUs got faster.
In my opinion the biggest issue with C++ is the lack of any kind of modules, and the author of the original post correctly recognizes that. Those endless includes multiplied by need for templates, produce ridiculous build times and make it impossible to hide implementation details (everythin g is still exposed via hpp-files).
Moreover, STL is beautiful. It was originally designed for Smalltalk if I remember correctly, and it's "ugliness" is nothing more than a bad implementation. Separating alogrithms away from the data types they operate on is a novel idea. Granted, you get it for free in dynamic languages, but STL goes as far as you can get in a rigid world of stone types.
I have been facsinated by C++, by its ugliness, its sheer size, hidden powers and fast code it generates. My interest in it has faded away as CPUs got faster.
In my opinion the biggest issue with C++ is the lack of any kind of modules, and the author of the original post correctly recognizes that. Those endless includes multiplied by need for templates, produce ridiculous build times and make it impossible to hide implementation details (everythin g is still exposed via hpp-files).
I can't say you're wrong, because it's all personal preference, but I guess those issues don't bother me as much. I copy and paste the errors and manipulate the text until I understand what's going on. This is cumbersome, and I wish the compiler would simply say "this has to be const," but it's not that smart. They should be that smart, and while I see that as a compiler problem, I understand it doesn't make a difference to the programmer who has to use it.
Binary size is a problem with heavily templatized libraries if debugging information is turned on; if not, there's no problem. I make heavy use of Boost.Spirit, and I saw my binary drop from 21MB to 3.7MB when I turned debugging information off.
And I guess API is just a matter of taste, although I do find myself making short wrapper functions for types of calls I make often. (Such as for_all as a wrapper to for_each on the .begin() and .end() of a container.)
Binary size is a problem with heavily templatized libraries if debugging information is turned on; if not, there's no problem. I make heavy use of Boost.Spirit, and I saw my binary drop from 21MB to 3.7MB when I turned debugging information off.
And I guess API is just a matter of taste, although I do find myself making short wrapper functions for types of calls I make often. (Such as for_all as a wrapper to for_each on the .begin() and .end() of a container.)
i agree with that. just std::string alone has saved me from years of pain.
I use C++ for image processing. Would I like to use Ruby? Of course. Do I know that if I do so I cannot process 30 frames a second? Yes. You take what liberties the problem at hand extends to you and save the dogma for the preisthood.
System resources are not as precious as they used to be, so the distinction has become more apparent. Hence, people who use C++ for non-systems programming encounter friction when performance goals are at odds with productivity goals. They then move to languages which take the opposite approach and sacrifice performance for productivity.
I use and like using C++. Yet I don't see any reason to argue when he says C++ is not for him any longer - he's probably right. I think the domain where C++ is appropriate has shrunk and continue to do so, and that's fine.
(For the record, rvalue references are a means to eliminate copying objects. This is, indeed, a performance optimization that most people don't care about.)