Why C Is Obsolete
softdevtube.com
softdevtube.com
in C++, you'd have a Matrix class with a getter. To get an element of the matrix you'd do
int v = pMatrix->get(i,j);
int v = matrix_get(pMatrix,i,j);
I dont see anything more than a syntactic difference here. The abstract reasoning behind the structures/classes is exactly the same.
C may be obsolete, but this is hardly a justification.
And it either (a) creates and destroys many intermediate structures or (b) templates everything by exposing the entire implementation to the user, resulting in slow compilation time and error messages that the domain expert couldn't hope to decipher.
Optimize when necessary. Until then, no need to mutilate expressiveness if the language allows it.
Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)
You also get destructors that let you have convenient clean up of locally-allocated data (boost scoped_ptr), which helps make sure you don't leak memory/reduces bugs/reduced thinking required.
That's all possible without pulling out massive standard libraries or using slow-compiling/hard-to-diagnose template-based libraries (merits of those I leave undiscussed).
My biggest problem with C++ is a lack of a standard ABI (perhaps this has been addressed by know, it's been a while). C libraries are dead easy to link to. You know what you're getting. C++--not at all, unless you live entirely in the same compiler ecosystem.
One of the biggest perceived problems with C++ is that people start thinking: "well, now that I am using an OO language, it's time to write some classes!" Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
If you're attempting your next project in C++, coming from C: only use those features of C++ that directly benefit you. Follow YAGNI. If most of your program is in flat procedures, alongside some objects, so be it.
Side rant: Consider that C++'s real uptake was in mid-90's, just as UML-ish diagrams began taking hold along with a massive rise of overdesign and no culture of agility. This led to massively overdesigned C++ apps. I'm sure the C developers were sitting there and wondering "Why the hell do I need all these classes? This used to be so much simpler." (I know I was.) Think about the horror that was J2EE--the same kind of thinking that led to J2EE also permeated C++ development at the time.
Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:
Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).
Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.
> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)
> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.
C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.
Curious: What's your domain?
In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Of course I'm saying this having moved past C++ for 99% of the development into an elegant and tiny scripting language called Lua, where you can do just about anything (including having an object system that you can change an object from one type to another trivially if that's what you want).
They went from ~34 fps to ~60 fps for 4 developer weeks re-writing the Lua code.
It is ludicrously fast. It usually loses to optimized C / C++, but by no more than 10-20% -- and you have essentially no restrictions whatsoever on the Lua features you use; Furthermore, it's FFI makes interoperating with C / C++ a superfast breeze, dropping the FFI overhead to zero.
And even ignoring LuaJIT2 -- they probably took less time and got higher quality overall by going through Lua (assuming programmers were equally versed in Lua and C++, and the infrastructure was reasonable) -- it's easier to iterate and debug with Lua than it is with C++.
OTOH, changing how you do things in Lua CAN be a big help in not generating garbage. I love the ability to ignore memory allocation in Lua, and I'm annoyed that I have to deal with thinking about it, but at least it's pretty straightforward.
Also, depending on the game, you can nuke your Lua allocation every level/section/other segment, allocating Lua memory from a memory pool. That can also help a lot with fragmentation.
But if you're doing a game that's one continuous experience, you have no choice but to be careful with managing memory. Again, it CAN be done from within Lua (think object pools), and that could be easier than porting to C++. And with LuaJIT 2, it would likely be fast enough in that case.
I switch every couple of years. Most recently: Image analysis; previously: Big data analysis; Before that: financial mathematics ("quant") and trading systems. If I go back long enough to '91-95: Game programming (SNES and PC); although I've been somewhat involved in game programming and related projects as late as 2008.
> In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Only if your logic is written in C++ as well. In the projects I was involved with, most of the logic was actually data driven or scripted, and C++ contributes much less in that scenario.
I don't deny C++ has its uses. But it also has a lot of drawbacks. Whether or not the net is gain or loss compared to $LANGUAGE, is subjective. For me with $LANGUAGE=C, it is negative. YMMV.
C++ challenges you to think in terms of types instead of functions. This is in my opinion often a more natural way to approach and solve problems and thus produces more elegant code. Because of that, C++ is a very powerful tool for library developers - you can design libraries that allow domain-specific developers to write expressive code that performs as if you had written more verbose C code. And this C++ code is not only more expressive for your fellow co-workers to read and understand but also in some cases for the compiler. This is the reason why C++ code can sometimes be compiled to faster machine code: you can give the compiler more information about what you actually try to accomplish (keyword: template meta-programming).
As with most things there is no definite answer. C code can be quite elegant and appropriate as well.
Thank the stars this didn't & won't happen!
Bjarne has been stuck in "C++ is the best & only language anyone needs" long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.
C occupies a sweet spot combination of:
- low-level with "no magic"
- small enough for most people to "hold in your head"
C++ matched these conditions for a brief time in it's life - the early 90s aka "Stroustrup 2nd edition" - when the only "magic" was basic virtual functions, and templates where just a promising experiment in an appendix.
This claim is clearly false on Mac OS X and X Window platforms, and disputable on Windows, with the increasing share of .NET apps.
Actually it is not.
On OS X tons of programs, and especially the very largest, most popular ones, are in C++ (think: Photoshop and the Creative Suite, MS Office, and lots of Apple's own: Safari (webkit) is C++, Final Cut and Logic are C++, etc. Don't confuse the front-end UI code (Cocoa) with the backend. C++ is a first class language in XCode, and you can mix it with Obj-C as Objective-C++.
On X Window platforms: besides KDE, some of the most important apps are C++, including Firefox, Thunderbird and Open Office.
On Windows there are almost no .NET apps that people actually use --people as end users, as opposed to corporations. Most of the popular stuff, from games, to office suites, to design suites, to browsers, etc are C++.
And if he's using Gnome in Linux, most are written in C.
But for Windows apps, commercial apps, cross platform and games, C++ leads by far.
Why do you ask?
What's "magic" about structs of function pointers? This is a classic idiom in C, just given a specialized syntax in C++.
I don't think this is true for everyone. In fact I believe recently we have seen a renaissance of native code. C++ is the number one language for that. Those higher level languages waste a lot of cycles. You pay the warm and fuzzy feeling during development with performance and/or energy.
If I can deliver a first version 2 months before the C++ version gets ready, I'll have two months to optimize market-tested algorithms before you hit the market. I may even have time to rewrite the sensitive parts in C.
If we are talking gadgets with embedded software, you may use a less powerful hardware and offer a cheaper product, but you'll have to amortize higher development costs and deal with a longer time to market.
For many things the world really moved on. C and C++ are still important, just not as important as they were a decade or two ago.
Yeah, the only problem with that logic is that it never happens.
(Except in the server space, where it doesn't matter what language you're using to make your web app, and you can throw more server boxes at it to make it go faster).
1) Very few commercial programs are made with some dynamic language as opposed to C/C++, and none in the fields where performance matters (games, video, multimedia) etc.
2) Some do incorporate a scripting language, but for non critical layers (Lightroom for example uses Lua for its UI scripting, but all image crunching is in C/C++).
3) It's not like time to market matters that much. You're not building Facebook, you're building a desktop app. Chances are a lot more exist in the same section of the market.
4) """For many things the world really moved on.""" --care to give some examples of successful desktop apps not written in C/C++?
I'm sure you'll find 10.
I doubt you'll find 20.
It still makes sense to use C/C++/hand-tuned assembly for high-performance things like game engines, 3D modeling, audio/video processing and so on. While my current OS is written mostly in C, I am old enough to remember (and have used) technically successful OSs written in things like Smalltalk, Lisp, PL/M and Algol.
Like I said, C makes sense for a lot of things. It's just not as important as it was 20 years ago.
People say that, but I don't see it. The Mac App Store has sold millions of apps already. And the iTunes App Store has sold a BILLION native (non browser) mobile apps.
If you only need is "a browser and a text editor" good for you. I need: a media player, a text editor, a word processor, an IDE, a chat client, Evernote, Dropbox, Skitch, Photoshop, VMWare Fusion, and some other stuff besides...
It all depends on where you look at. I can't remember the last corporate software piece I saw being delivered as a desktop application.
Stand-alone software for iOS has one advantage over web applications in that users sometimes face lack of connectivity. The Facebook app, IIRC, is delivered as a standalone app, but, in reality, is nothing but a web application. It's not alone and there are definite advantages to their approach. Most software appears to be entertainment - games, social thingies etc. They are the kind of games one would expect to be delivered as a Flash application within a brorser on a desktop.
I am not familiar enough with the Mac App Store, but, while there are some more "serious" offerings, in line with the desktop apps I mentioned, most of them appear to be, again, games and other entertainment related stuff. That and front-ends to net-centric applications such as Evernote.
C++ is used heavily from everything from Games, VFX programs (modellers, renderers/raytracer, compositors, paint programs), autopilot and control systems (cars, fighters (JSF), SpaceX are using it for their systems on their rockets), database systems, webservers, etc, etc.
There's a reason it is used a lot - in the real world it gets jobs done well by people who know what they're doing with it.
Saying "the world has moved on to Java, C#, etc, etc" is pushing it, given that the base system for many of those things are written in C++ (most of the native JNI stuff is C++, most Javascript compilers/interpreters are C++, many databases (Oracle, MySQL, MongoDB) are written in C++.
You may not like C++, and it might be difficult, and it may have worts, but thousands of people are using it very successfully for things no other language can do to the same degree overall.
I meant something like: other languages have risen in popularity because they are better than C++ for many types of projects.
Unfortunately, the reason why this hasn't happened is inherent: C++ is so utterly complex (the C++11 standard contains more than 1300 pages of highly compressed language legalese) that especially in the embedded systems domain many vendors just don't have the time and resources to build a C++ compiler. And being caught in this vicious circle, embedded developers still aren't (and probably won't be for still quite some time) accustomed to programming at higher abstraction levels than what C offers. This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry.
You just proved that it is too inefficient... too complex to efficiently implement dev tools for use with (some) embedded device's to-market development cycles in a timely fashion.
Any language that takes the better part of a year to develop an adequate parser for is NOT to be trusted.
I had a long rant on RTTI, templates, the positively miserable experience around exceptions, and so on. But you've heard it before.
C++ should have /started/ with a string class and a set of collection classes, rather than having them be bolted on a decade later. This would have driven the language in much more useful directions.
I don't know if it's possible to remove features, but I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language because they are dangerous, fragile or make bugs.
My experience with OS-level development is that you get a better code with vanilla C.
A lot of people use C++ to code as they would in Java or C#, generally their experience is terrible. Exceptions don't work the way you think they do (in C++ exceptions should be exceptional). Polymorphism is more verbose, it's not introspective, etc. There's much to say about it.
I've found you enjoy the language much more when you go generic/functional full speed. You also understand why some arcane features of the languages are there (such as the .* operator).
Actually you can. You don't remove them from the existing language that is, you make a better language with bs/redundant removed.
While "every person uses a different subset of C++" is true, it's not like everything someone uses is equally beneficial to have in a language. As the parent said, what is useful and what is not is not that controversial:
"I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language"
Operator overloading.
Doing non-atomic work in constructors (allocating memory, doing file I/O, etc.).
RTTI
Template metaprogramming
... and more
It is my basic belief there should be many tools in a developers toolbox and you should not always use the hammer on a screw or a very precise scalpel when trying to remove a sliver when a pair of tweezers will get the job done.
If you want to declare a language obsolete I recommend we discuss a language that is not in the top three!
Yeah right, a language/platform is a bag of fun toys out of which you can pick whichever ones you want, and all is well and everyone is happy. How can a programmer who has any experience claim something so ridiculous? When you decide on a platform, you have to live with whatever is there, the good and the bad. You can't tell people to use some feature but not touch this library, or not include that other package but write yours instead.
* group code into functions * group primitives into structures.
However, it's simplicity is it's strength. You can write clean, standardised code in it. It's clean and simple. It's obvious. It's far too easy to make mistakes in C++ from bad type conversion or bad inheritance models (e.g. forgetting to virtualise something) to confusing subtly broken operator overloading that's counter-intutative.
C++ does render a C a little bit redundant. The abstractions it provides not only make programs more maintainable, but that additional intent allows compilers to potentially generate faster and more portable multithreaded code. We hit a point where C programs compile to faster/better assembly than a human can write. I expect that soon we'll hit a second wall where the C++ compilers can write faster/better multithreaded code than a C programmer could write or optimise and a C compiler couldn't support that directly "intent" as the language doesn't facilitate describing it.
However that point hasn't come yet. C still benefits from being clean, easy to interpret (from a human perspective) and is a demonstration of how to design a new language.
C++ is a federation of languages but writing pure C with gcc is better than g++ with all warnings enabled IMHO.
It would be so easier if the only difference between compiling for C or C++ was whether or not symbols were mangled or not. Someone writing C code that nevertheless calls C++ code could still compile with the C compiler, instead of today's solution, specifically - wrap the file in #ifdef __cplusplus extern "C" { #endif
and compile with the C++ compiler.
Plus, no more need to deal with all of the different flags leading to CFLAGS, CPPFLAGS, CXXFLAGS, no more worrying if a bool is a bool or a _Bool etc etc etc
Of course, care would need to be taken to not needlessly drag in the C++ runtime if it is not used.
c is still one of the most efficient languages out there next to assembly languages, you have complete control over memory management, most of the compilers produce highly optimized native code across multiple platforms, and there are a wealth of system level libraries to do some really significant things, i.e. it's as close as you can get to bare metal without having to deal with machine code.
i want to be clear here because i have been on both sides of the fence writing enterprise software in c as well as more recently in java, python, ruby, etc, so i know the advantages (and disadvantages) of OO versus a procedural language like c which i'm guessing is the major argument of the article. having libraries and frameworks like ruby on rails will significantly increase productivity and time for development, which in itself is a major win, but when you're talking about maximum performance, c is probably your best choice.
in general i think that writing software in the 21st century is still too complicated and error prone. if i want to write a web app, why do i still need to parse strings, perform database queries and such? why can't i have higher level abstractions or frameworks/libraries that give me this functionality. that's why i like django and rails, they seem to be moving in that direction (convention over configuration), though at the end of the day, you're still working with strings, arrays, and such. we should have software systems that provide even higher level abstractions than components and frameworks, for example, i want to create a social networking website that stores billions of 140 byte character messages, these messages should be searchable, this needs to run on iphone, chrome browser for windows, linux, etc. it would be great if the focus was on the features described like above and functionality rather than having to deal with SQL, arrays, strings, templates, css, ajax, etc. maybe the closest thing to this is like packaged software where everything is pretty standard and you customize only the portions that are necessary (maybe like twiki). i should never have to deal with SQL or even ActiveRecord (even though it's a nicer abstraction over SQL), all this logic should be taken care of for me, i should only have to define the high level stuff. when we get to that point, that's when i believe that we'll have achieved 6GL.
7GL would be where the software would have enough intelligence to figure out that it needs what features and have those implemented automatically.
He also pointed out that he worked closely with the late dmr (office was just three doors down the hall) and still has strong ties to other famous and well-known C gurus (dinner with Brian Kernighan) and that C and C++ coexisted w/o issue in their world.
His final point was the best though... he pointed out how programmers argue and fight about which is better, not the designers and researchers themselves.
Edit: Also, the new C11 standard brings C closer to being a complete subset of C++ and subsequent standards will continue doing this until they are merged, but this won't make C obsolete.
Of course, I'm atypical - when I'm not writing in C it's because I'm writing asm.
The only serious alternative system programming languages have been offered up by Niklaus Wirth and associates. Not much traction among developers...
Long live C!
On the other hand, from a fully practical view, even after omitting all incompatibilities a C code compiled with C++ compiler will be bloated with C++ standard lib, and will have screwed symbols.
~
Instead, let's talk about things that C++ got right that aren't super obvious! :)
For me, one of the coolest things about C++ is having destructors. The neat thing about them is that they are based on the scope of an object, and tie directly into when the object leaves scope in the language (as determined at compile time). Any code there gets run when the object is deleted or leaves scope, and this is guaranteed to happen immediately.
So, I know exactly when an object is no longer "needed", and if I'm careful I can use things like smart pointers and reference counting to guarantee that a shared resource gets removed when it needs to. I can also override new/delete and do some magic to have a reliable "hey, come free me from the heap later" behavior--when the destructor is called, have the class append itself to a list of things to be GC'ed when the time is right.
Java, for example, doesn't do this--a request to finalize may be fulfilled, one day, when the VM feels like it. This makes smart handling of things like system resources really clunky, and can force me to write C-ish code like freeSystemResources() or something. Having an ability to explicitly know when lexical scope has been left is pretty cool.
What other cool things have you seen in C++ (or C)?