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..."
Balkanization (Score:5, Interesting)
Though it were hard for me to imagine, for instance, Unreal [wikipedia.org]'s engine being ported to Java, Quake [wikipedia.org] seems to have fared well with feral C.
Re:Balkanization (Score:2, Interesting)
Of course I always figured this was just my weirdness, I never realized anyone else felt this way about it. I sure don't miss those retarded C++ references and stream operator overloads.
Less C++, more Ruby (Score:4, Interesting)
I feel sad about not using C++ more often though, because it really was my favorite language for a long time. I just can't think of any project idea I have where C++ would be better suited than Ruby.
C++ has its place (Score:1, Interesting)
Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...
C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for
Objective-C - Is it used ever outside of Apple development?
Smalltalk - Nice and pretty. And unheard of outside of the niche.
Python, Ruby, etc. - Often considered too slow.
If anything, Java/C# are dying. The reason: Python, Ruby, and other interpreted languages. C/C++ blazes Java in speed, and the interpreted are much faster (and easier on the eys) in design. In fact, if everybody switches to Python (can't say about Ruby), C++ will continue to thrive due to Python's adherence to C/C++ module. Implement in Python; tweak in C/C++. Where would Java be?
Re:Balkanization (Score:5, Interesting)
And just a few days ago I was reading on slashdot about Java/C# falling in between C/C++ for low-level systems programming and the "dynamic and/or scripting" languages for highest productivity (e.g Perl, JavaScript, Python, PHP, Ruby, Haskell).
Re:C++ has its place (Score:5, Interesting)
C++ remains as the only proper object-oriented language. Despite all the years of continuous development in languages, there has yet arisen an overall better object-oriented language. Yes it's ugly. Yes it's cryptic. Yes, it explodes often. But there isn't another language that does things better.
C++ the "only proper object oriented language"?!? It started life as a kludged on Modula extension to C. It has evolved into an overly complex language that includes elements of many programming paradigms, but implements all but the procedural ones poorly. The procedural stuff came from C anyway. Objective C is far closer to a "proper" object-oriented language, adding the minimum to C to give it OOP features. Smalltalk itself is the purest OOP language.
Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...
It inherited procedural syntax from C, not C++. The OOP aspects were inherited from Objective C and SmallTalk, along with a class library that owes much to NeXTstep/OpenStep. Gosling and other Sun engineers must have been exposed to NeXT's development platform during the brief Sun dalliance with OpenStep. As for being controlled by a "business" committee, my experience of Java's evolution is that it was largely driven byb engineers at Sun. Anyway, Stroustrup and the ISO committees haven't done a great job with C++.
As for being a C++ killer, it seems to be exactly that at my current employer. Our content delivery systems have been rewritten in Java and C, replacing a C++ monstrosity. Our only outsourced application is in the process of being rewritten in Java rather to replace the current C++ version from the same vendor. C++ ain't just dying, it's dead here.
C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for .NET. Stupidity for everyone!
Although it's just Java for Windows, C# is a much more elegant language than C++.
Objective-C - Is it used ever outside of Apple development?
Why's that, doesn't development for MacOS X amount to much then? Plus, the Cocoa APIs are far more elegant than the hideous STL abomination.
Smalltalk - Nice and pretty. And unheard of outside of the niche.
It was ahead of it's time, but obscurity doesn't mean it's a poorer language than C++.
Python, Ruby, etc. - Often considered too slow.
Only in urban myths.
Video Games (Score:3, Interesting)
Re:Balkanization (Score:3, Interesting)
No matter what else it does the slow part is entering kernel mode and printing characters to the screen.
You are discussing a 20ns optimization on a 1ms call.
Re:C++ has its place (Score:3, Interesting)
Only in urban myths.
No, in practical use. Try doing something like image processing in those languages; or (perhaps more realistic) parsing a large XML file with native Python or Ruby code. Now try it in a C++ or Java parser. The difference in speed is phenomenal.
Re:Balkanization (Score:2, Interesting)
He should apply to Microsoft, I hear they can use some help.
Re:C++ has its place (Score:2, Interesting)
Stuff like the JVM,
As for the ISO standard, it's only a standard. After all, C++ technically belongs to nobody and anybody can add information to (GCC) compilers. GCC had many C99 commands awhile before C99 was published. Nobody can easily add Java syntaxing, support, etc. (although GCJ is getting quite good so this may be moot).
Re:Balkanization (Score:4, Interesting)
OK. puts is faster. But I hate to break it to you, compared to cout, puts sucks.
puts is error prone in a way that cout is not. More appropriately, cin is far, far superior to get and all those derivatives. cin, cout and cerr, are slower, have more overheads, take more space,etc, etc. I still prefer them. Why? Because they're safer. Not totally safe, but leauges safer than the equivilent c functions.
On top of that you can overload cin. Some people do screw this up, but being able to write:
while(cin >> Big_Complicated_Object){
}
Is very sweet. C can only offer me this with hacks that will freeze thy young blodd etc, etc, etc.
I don't find C++ too bad. The compilers are OK, and I don't abuse the language features. I'm an OO kind of guy, and I like decomposing my programs. C++ lets me do this in a way C cannot.
Re:From my point of view (Score:5, Interesting)
I got over my dislike of C++ about two days ago when I decided to use Qt to do some programming, which pretty much forces you into C++. I was really shocked at how unpleasant it *wasn't*. I've had some really bad experiences with Java - a lot of "model" is forced down your throat. Using C++ felt very natural, and I noticed a huge number of really nice touches that are quite cheap, because they're done by the compiler, but that (a) make your coding less error-prone, and (b) are just horribly convenient.
So my point here is that if you've been hearing for years that C++ isn't worth your time because it's object oriented or because it's just C warmed over, neither of these statements is true. I'm embarrassed to have ever repeated them (sad to say, I have done so in the past).
I really don't think C++ is on the way out. My main complaint about it at this point is that g++ is too verbose when I use an overloaded function that doesn't exist - it prints a list of all the possible candidates, which can get quite long. I don't think that's a capital crime, though.
Re:Video Games (Score:2, Interesting)
That's funny. I've written over 15,000 lines of C++ code over the last year in my spare time, and run it all through valgrind. Haven't had a memory leak yet. Using RAAI and the STL, I can't even think of a way I could get a memory leak... maybe if I leaked whole objects, but I apply the same discipline throughout my programs that I apply to memory allocation (of which I do very little).
As for buffor overflows, once again the STL helps a lot. For the rest of it, a little discipline goes a long way. Buffer overflows are a lot harder to reliably check for with automated tools, but I've gone over the code looking for them, and haven't found one yet. It's not that hard to program in a way that makes this stuff almost impossible, it's just not a lot of fun. My solution to that is to program the not very fun stuff in a real general and safe way so that I can reuse it and never have to write it again. Keeps you going if you know that when you're done you're done.
Re:It will be a happy day... (Score:3, Interesting)
While D certainly has some good points, I'm not entirely certain that even Walter Bright is certain it's entirely ready to take over as the premier language. Since you posted as AC I don't know if you read or participate on comp.lang.c++[.moderated] on a regular basis, but if you've been following all the threads, you'll notice where DbC is being discussed, and D is being used as a prime example of how to completely screw things up. Walter is participating in those threads, but so far he seems mostly interested in learning how things should work rather than claiming that D really has it right (for those who didn't realize it, Walter Bright was the inventor of D, as well as the author of the Datalight/Zortech/Symantech/Digital Mars C compilers for C, C++ and D).
Ah, it sounds like you probably do not follow the NG much, if at all -- if you did, I'm sure you'd realize that for people who already know programming reasonably well in some other language, Accelerated C++ is, far and away, the recommended book.
The reason for const parameters is simple: they restrict your access to the object so passed. Restricting access as much as possible at any given time prevents accidents, making for safer programs. '*anything' has roughly the same meaning it has in C -- you have a pointer(-like object) and '*' dereferences it. It's possible to overload the (unary version of the) * operator (or nearly any other operator) to do something entirely different, but it's generally poor style to do so. Operator overloading does give the programmer the power to do really bad things, and produce horribly obfuscated code, but it allows the programmer to do really good things, and produce much clearer code than is generally possible without it (e.g. overloading for matrices and complex numbers).
Specifically, it's converted by a constructor. That's exactly what the constructor is for, and it's apparently doing its job exactly as designed. Do you have some objection to things working as they're supposed to?
This is far from a pointless feature -- while most Java textbooks fail to mention it, this is one of Java's larger shortcomings. Making a function non-virtual says something specific about the design -- that the function in question is invariant across all descendants. The Java language simply fails to allow that concept to be expressed.
Declaring a method const also has a specific meaning -- that the method in question does not alter the logical state of the object. Again, this contributes to the safety of programming. It's true that many languages are utter failures in this regard, but this is an area of strength in C++, and rather a shortcoming in many alternatives.
Rather the opposite. GC and it's non-deterministic destruction (finalization) of objects prevents you from using RAII. The fundamental difference here is that RAII can be applied to nearly all kinds of resource management, where GC only applies to memory.
Back before RAII was well developed (or at least before I u
Leadership (Score:4, Interesting)
talking about them being dead and that was one of the better moves
I've made in the stock market... I imagine all the Sun people are
really concerned too; they're as good as dead. I suspect redbull is
killing coke too, they are probably dead.
I like C++, I like the idea and the intent. After spending like 10
years going through standards processes, I actually like the end
product and the STL and what have you, it's substantially more clean
that it was in 1991. I think they got a good 80% of the way there.
There is still some jankiness though.
I think the thing with C++ that is larger is that they are still old
world. There is no quick movement and there still isn't any "21st
century" development style in the standards group. Java has warts but
one of the great things it has going for it is Sun produced a lot of
standards and then the jakarta group did the same and there tends to
be a lot of similarity between "high quality" java products and
components. There is a ton of java stuff to reuse and the code tends
to be be laid out in a similar way, built in a similar way, javadoc is
used, xdocklet is used, etc.. C++ doesn't have any of these standards
working for it and there aren't any major projects (maybe KDE and QT)
that are really sort of laying out the guidelines and building
reusable components. In short, nobody is really showing everyone else
"how to do it." I think that alone has accellerated java at a
remarkable rate.
Beacuse of all of that, I don't know of a lot of good high quality
C++ reuse. There are some knickknacks that might be reused. Then
there is kind of this whole-world style framework, like QT which
includes tons and tons of stuff. Simple little libraries don't seem
to be popular because there are so many different ways you can use
them, different conventions, etc.. Every time you start a C++
project, you're starting over from scratch. The other thing java has
helping it is the class library. You cna buy Roguewave or something
but there isn't a good opensource alternative. Boost is kind of
filling the gap but it's still a little project and I think the scope
has stayed fairly small for a lot of reasons, many of which are
political.
Part of this is the C legacy and the C++ attitude, it let's you do
things "your way." And the languages tries not to do "too much" yet
it's supposed to compete with higher level languages that are totally
tricked out with features and libraries. I think if you were
starting a new large scale application project and Java wasn't an
option and mono/.net wasn't an option and you were looking at C++,
GNAT would also have to be considered (as radical a thought as that
is) because I think there might be as much or more high quality
reusable componets that you could harvest for it.
It just needs a really strong leader and some community built up
around it. Define some common framework rules. Write a couple
frameworks, if I could just instantiate a socket class (with SSL as a
yes/no flag) and create a high performance and high quality C++ server
network server in a small chunk of code, in a standard like way,
that'd be cool. Imagine that it had some template based policy stuff
that allowed me to plugin validators and crap like that and we created
a nice reusable network component and started to make some of the
security holes in that stuff go away... Simple and clean, reusable.
WOuld you write your own server everytime now or would you use this
one?