Demise of C++? 271
fashla writes "Several somber and soul searching threads have been recently posted to the USENET newsgroup comp.lang.c++ such as "C++ is Dead" and "A Dying Era". The reason for this reflective mood is the sudden demise of the magazine C/C++ Users Journal (CUJ) http://www.cuj.com/ that had been published by CMP Media. Participating in the posts have been such C++ luminaries such as Bjarne Stroustrup and P.J. Plauger. While some contributers think that CUJ's demise is due to the general trend away from print, others think something else is afoot..."
Re:Balkanization (Score:3, Insightful)
From my point of view (Score:4, Insightful)
The problem with C++ is that it is neither as simple as C nor has it the benefits of Java and C# as they allow for code that is easier to read and understand. The available tools are also better for the competing environments on the upper side.
C is still developing features at a slow but steady pace and it has inherited a few from C++. There will probably be more features inherited in the future, which will cut more into the area of C++. The difference between C and C++ is that C isn't object-oriented while C++ supports object-oriented design. But object-oriented design is not necessarily needed at the low-level programming that is used when accessing devices and similar operations, and hence C will be the choice of such programming.
Nah (Score:5, Insightful)
What we are noticing today is that programming languages alone just don't cut it anymore. The software is so advanced, that standard language constructs and libraries are way too raw to be applied to something useful for the average application programmer. Knowing frameworks, APIs and libraries is becoming a lot more important than using all the language paradigms and hidden tricks.
I think C++'s user base is splitting: On one hand there are the library and API developers, for whom the standard and the language are wholy. On the other hand, there are the application programmers, who care about the practical side of the language; they use it because it has advantages over other languages and has lots of libraries written for it.
My belief is that C++ is more alive today than ever. It is more powerful than ever. And it will be for a long time (in technology terms, indeed). Of course, in 10 years time it won't be recognizable. But it's wrong to say that C++ is dying.
Re:Balkanization (Score:2, Insightful)
We just got tired of being insulted (Score:5, Insightful)
Widely used languages don't die quickly (Score:3, Insightful)
http://www.dedasys.com/articles/programming_langu
( although my hosting provider's network seems to be running a bit slow:-/ )
C++ : to remove yet another sucky java app. (Score:2, Insightful)
The initial Java implementation had too large a system footprint (we required it to run on fairly low spec machines with limited resources).
The rewrite in C++ ran smaller, faster, and without the Java "slow to load and start" TM.
The trade-off for the re-write was the longer development cycle.
Overall, we don't see C++ dying, but as a great tool, which still has it's place.
Re:Balkanization (Score:5, Insightful)
But v-tables are only created when virtual functions are used in classes, and only then. If no virtual functions are used then a C++ program can use static linking the same as for a C compiler. Given that C++ compilers are also defined to be C compilers, then for any given C++ compiler (and no virtual functions in the C++), C and C++ code should run at the same speed.
Now if you want to compare *different* C and C++ compilers, that is a seperate matter.
If you are interested in the inner C++ workings I can suggest any of the Scott Meyers books. Other people can probably suggest other authors as well.
Re:We just got tired of being insulted (Score:5, Insightful)
We're just plain tired of giving the same answers to the same people who never listen and carry on regurgitating the same crap they heard from some uninformed idiot. There's one thing that's very obvious from the numerous appearances of C++ on Slashdot recently: very few of the readers here have actually used C++ in any serious way.
You're only hurting yourselves when you dismiss C++ out-of-hand for uninformed reasons.
Print is in a coma... (Score:2, Insightful)
translation: LA LA LA LA, LA LA LA LA (Score:3, Insightful)
C++ is kind of a monster of a language (almost as bad as Perl), but it is one of the few I'd choose for the niche where speed/space really count. Unfortunately for C++, there are very few programs for which this is the appropriate niche. Most of the C++ that crosses my desk should have been written in an appropriate scripting language (insert your favorite, Python's currently mine). I even heard a tale of someone writing a "makefile" in C++ (gawd). These mistakes cost a lot of time and money.
My biggest problem with C++ is the apparent lack of a decent conforming compiler (preferably with useful diagnostics). Every few years I check and it seems like they're nearly there...
depends on who you work for... (Score:2, Insightful)
Re:Balkanization (Score:3, Insightful)
My personal opinion has always been one of pragmatism instead of zealotry; pick a language based on the task. It has been said by knowledgeable people that the benefit of OO over procedural is not theoretical performance but rather the practical performance. OO techniques typically allow one to better understand large problems and thereby create better solutions. Ofcourse, reengineering those solutions to procedural code would make them faster, but would also limit maintainability since you'd be creating less a "clear" solution again. In short; a solution in procedural will likely be more complex than the same solution in OO.
IMHO, C++ in the hands of a well-thinking human should never be any slower than C, but may just be faster. The issue is not whether either language is inheritently faster, but how to educate the developers to work with multiple paradigms.
Re:Balkanization (Score:3, Insightful)
Re:From my point of view (Score:5, Insightful)
You're way off. So far that I'd say you've never read or written modern C++ code. There's a lot of metaprogramming. Look into templates sometime. Try out the STL and the boost libraries [boost.org]. There are significant C++ programs that are not object-oriented and would be nearly impossible to duplicate in C with the same kind of efficiency.
I find C++ to be an ugly, ugly language, but it's also a lot more than the "C + classes" that it used to be.
Death by subscription? Please. (Score:5, Insightful)
So, I don't think that C++ is going anywhere because the journal is going away... I think instead people who are using C++ will go elsewhere for information about C++.
No story here... move along.
C/C++ dying? What are they smoking? (Score:3, Insightful)
IMHO, C/C++ is far from dying. It's getting stronger than ever atleast in the realm of software engineering. I see it finding it's nitch closer to the hardware and in core of advanced software where speed and optimization is important.
Like, you wouldn't write a 3D game engine in java, atleast not yet anyway.
Look at KDE what is it written in? and Unreal? What is the JVM itself written in? and
I still see that software engineers are still using it heavily where as the rest of us mortals in the business realm, develop in other interpreted languages that can offer faster development time. Cost is everything, we programmers are no longer seen as an asset but more as a cost. Java and Lamp programmers are just cheaper.
I find it very unfortunate that schools are no longer teaching C++ and switching to Java.
The end result is a more limited amount of advanced C++ programmers out there working on very important advanced applications.
C++ is more like Perl... (Score:5, Insightful)
But what I've told people again and again is that *you* don't have to write it that way. Don't understand multiple inheritence? Fine...*don't use it*. Don't get templates? Fine...*don't use them*. We still use VC6 and its template functionality isn't even complete!
The truth is, you can have bizzare WTF moments in *any* language. A lot of what people attribute to the failure of a language is the failure of a programmer to properly explain what his/her code does in a straightforward way *using the code itself*. The best code is clean and concise and C++ gives you as much opportunity to do this as any language. Sure you can have multi-thousand line functions in C++, but this isn't a failure of the language to somehow magically break it apart for you into better organized bits, it's a failure to understand that a language, *any* language, whether purely written or even spoken, is to convey a message, a story, and without careful attention to detail, can become an unholy mess (like this post).
Re:C++ has its place (Score:3, Insightful)
I've done a lot of XML (and SGML) parsing using toolkits written in C, Perl and Java. The C ones (expat, libxml2 and several commercial packages) were quick, although the nature of XML means that a lot memory allocation goes on. The Java and Perl toolkits behave well because memory is pooled at the userlevel, rather than requiring many malloc calls. Image processing on the other hand, is why the system I mentioned above has some parts coded in C. ImageMagick, using the raw C API, narrowly beats a similar processor written to use PerlMagick. However, the C version needed a fair bit of testing with tools like Purify to ensure it didn't leak memory. Both the C and Perl processors were written to replace a C++ application that used Magick++. It leaked memory and was a nightmare to debug.
Whatever. (Score:5, Insightful)
Among all the programming languages I've used over the last 25 years (6502/6809/m68k/... assembly, Prolog/Miranda/... functional, Perl/Tcl/Python/Lisp/Java/... interpreted, C/C++/PL-1/... compiled), only 2 really stand out as "excellent" tools:
C++ and Python. I really have to struggle picking which one I love to write programs in more. They both have their place, and they are both lovely in their own way.
As far as C++ goes, since it exposes all the "knobs and dials" of the underlying computing architecure, it does have a very long learning curve. However, Template Metaprogramming is unlike anything, available anywhere, in any other language.
Listening to all these Java/C# fanboys flame C++ templates, and compare them to "Generics" etc., is like listening to guys compare their cool Ox-Cart wheel mods, while saying how much that new-fan-dangled "ferr-ar-eee" Sucks...
Yes, it took *years* for me to master C++. Someone smarter, and/or with better (read: any) instruction would -- and should -- do better. But, being able to express an algorithm purely, which will compile efficiently to process *any* type(s), stored in *any* container, accross *any* architecture, with full static type checking and bare-metal hand-coded assembly language efficiency, is something truly unique in the programming language world today.
When some other language comes out with something better and more efficient than Template Metaprogramming, let me know. 'Til then, its C++, baby!
Re:Balkanization (Score:2, Insightful)
Re:From my point of view (Score:2, Insightful)
Re:From my point of view (Score:5, Insightful)
My experience with C++ and Java is that Java is simpler to get your head around, but can really get annoying once you get going, because of the number of gross hacks and workarounds required to avoid excessive heap allocation. Compared to C, C++ often results in dramatically clearer code, simply because it offers the ability to wrap things with enough syntactic sugar that it makes source code much more concise.
However, taking advantages of C++'s strengths requires some discipline, and requires programmers to understand what's going on to some degree, and as we all know, the great majority of programmers are idiots.
I suppose in the end, the best progamming language for idiots will win...
Re:Whatever. (Score:2, Insightful)
However, Template Metaprogramming is unlike anything, available anywhere, in any other language.
Thank god for small favors. Templates are great, they do what they are supposed to, which is to all for more generic programming. Template meta-programming otoh is an evil movement to half-ass add features to a language that doesn't have them. If you want Lisp macros, please by all means use Lisp. But don't take something good (type-safe generic programming) and turn it into a tool for evil. Yech, you're probably one of those guys who show off the compile-time recursive fibonocci sequence trick.
Re:C++ : to remove yet another sucky java app. (Score:2, Insightful)
1) compare performance to a total rewrite in Java, given the experience gained from the first round.
2) normalize for programmer expertise in the two languages?
I'm guessing not.
Re:C/C++ dying? What are they smoking? (Score:3, Insightful)
In an anecdotal way, a relatively mature and competent C programmer could take a good shot at implementing a C compiler and come away with something pretty close to the real thing, because C is, well, simple, and consistant. C++ on the other hand -- it's so huge and complicated that I don't believe there has ever been a compiler that implements all of it, but correct me if I'm wrong on this. Needless to say, that level of complexity is troublesome.
In the old days -- by which I mean a decade ago -- we were still constrained enough on memory and CPU that C and C++ were the dominant programming languages for application development, with no sign of that ever changing. Dropping in on usenet would easily yield a religious C/C++ war with some C geek saying "C++ is bloated and slow" much as we say "Java is bloated and slow" today. It's laughable now. C++ may be slightly slower than C, but even without recent compiler advances by todays standards the difference has essentially always been negligible in well written code.
What I'm trying to point out here is that the focus in software development has changed drastically in the last decade. Unless you're in the embedded market, there are hardly ever CPU and memory constraints, and every corporation worth its salt has started to see that there may be something to languages that are easy to maintain and quick to develop in, even at the expense of speed (which is hardly ever relevant in a typical desktop or web application, which is what most application dev is these days).
Looking back, I think it was the web boom that changed everyone's perceptions. In the old days, you did all serious programming in C or C++ and everything else was either scripting or esoteric. But the first CGI scripts were, well, scripts. They were increasingly written with more and more powerful languages (more powerful than scripting languages, I mean) -- languages like perl, java, whatever -- and brought closer and closer to the webserver to increase their responsiveness and power -- but no one ever seriously considered writing these apps in C or C++, because it had been established historically that the pain and suffering, the bugs, the slow development cycle -- well, it just wasn't worth the effort.
I believe the explosion of web based services taught IT managers everywhere that C and C++ were, at least, not the only answer to the question of "what language should we write this thing in". CS folks have known forever that it's "the right tool for the job", but CTOs have generally always been partial to whatever language is vogue, without understanding the pros and cons at a deep level. So in the old days it was FORTRAN or C, then C++, then Java, Perl, C#, Python, Ruby -- the doors were opened by the whole web thing.
The result is, nowadays, C and C++ are increasingly less relevant. I say this as a die hard C programmer, mind you. C and C++ are increasingly used in relatively special environments. Embedded. System kernels. Drivers. That sort of stuff. In these fields, C++ is hurting. While I'd love to say it's because everyone recognizes that C++ is inferior, because I've always disliked C++'s hack-it-all-on approach, the truth is that legacy has a lot to do with this stuff. In the embedded market, resources are still so constrained that in many cases even pure C is not efficient enough -- they write programs in special subsets of C that have a lot of features built in to the language that take advantage of the somewhat exotic hardware they need to run on. So C++ is out, but then, strictly speaking, C didn't cut it either.
Kernels, well, the truth is that of the systems kernels in use these days, most of them predate C++ (or at least, th
crossroads (Score:2, Insightful)
Lets hope it can pick up some of the contributors we have all grown to appreciate over the years, Herb Sutter, Andrew Koening & wife, Lippman (who's doing MSDN mag), etc.
C++ has always taken what's good (STL), and dropped what wasn't (auto_ptr), and now more than ever developers using it will require assistance in understanding some of the latest developments in the language (Template MetaProgramming, concepts).
Sure the web is great, but a mag allowed for a monthly round-up in a easily accessible fashion, of all the language features (and darker corners).
We will have a C++09 standard, and for those of us using the language daily in creating apps that must sell, I believe there is a cross roads: Do we continue on using a very powerfull language, all the while having a harder time to find programmers knowledgeable enough to use it properly, having C++ magazines replaced with
I'll admit that a team of 6 C# devs may have an advantage over a team of 6C++ devs in the time to create software, to debug and test it, the available documentation, and the power of the language. Sure their code will run slower, but they rely on the Stan Lippman\s and Herb Sutter's @ microsoft to provide a good overall library...
Re:Balkanization (Score:3, Insightful)
Is that the same C# that a friend uses, which apparently requires 12 bytes of memory to store a single 32-bit integer?
If that's accurate, then I don't think C++ has much to fear from C# in its natural areas of strength...
Re:translation: LA LA LA LA, LA LA LA LA (Score:5, Insightful)
The RAND corporation says that more than 70% of all software is embedded software. Embedded as an industry is almost universally C++. Please do not confuse being in a different branch of the industry with a branch of industry simply not existing.
What's really wrong with C++: denial (Score:4, Insightful)
C++ is the only remaining major language which has hiding without safety. C has neither. Java, C#, the Pascal/Modula/Ada/Eiffel family, and all the scripting languages have both hiding and safety. That lack of safety is responsible for most of the crashes and exploits in today's software. When a virus takes over your machine due to a buffer overflow, it's probably because of that bad design decision in C++. Every day, hundreds of millions of people must suffer because of that mistake.
The largest single problem comes from the decision in C to treat a pointer and an array as the same thing. This seemed convenient thirty years ago, but created a language in which the size of an array is not permanently associated with the array. In particular, the fact that arrays are passed to functions without size information is a huge source of trouble. This, of course, is why we have buffer overflows.
Attempts were made in the STL to fix this problem, but it didn't really work out. Trying to retrofit strings to the language via the template mechanism was not all that successful, since so many libraries and system calls required the old-style strings.
Safety is not a performance issue. It's possible to do checking very efficiently, if the compiler knows what to check. Subscript checks can usually be hoisted out of inner loops at compile time. But this is not possible for C++, because the subscript checking, when enabled, is in the STL, not the language.
The second big problem in C++ is the need to obsess on "who owns what". Memory allocation is the nightmare of C++. Again, the STL tried to address this, and again, it was botched. The auto_ptr debacle illustrates the limitations of the language. There have been many, many attempts to implement "smart pointers", and they're all unsafe. At some point, you have to extract a C-type pointer to get something done, which introduces a hole in reference counting. If you don't extract raw pointers, you spend too much time updating reference counts. Again, this is something that a compiler could optimize if the compiler knew more about what was going on. But with reference counting implemented at the macro level of templates, that's not possible.
Garbage collection is occasionally proposed as a panacea, but it's not compatible with the concept of destructors. In a garbage collected language, what destructors and finalizers do must be severely limited. This is contrary to the C++ concept of "resource allocation as initialization". You don't want to close a window from the garbage collector. Also, introducing garbage collection introduces a form of concurrency, in a language that doesn't handle concurrency well. There are workarounds for this, but like most workarounds, they're painful. Take a good look at how Microsoft's "Managed C++" approached the problem. It's wierd; read about "resurrection [c-sharpcorner.com], where an object comes back to life during garbage collection.
Those are the two elephants in the living room of C++. Denying them will not make them go away. This is harsh. But it's not wrong.