I don't think there's any question that C++ was a dominant force throughout the MS Windows era of the 1990's and early 2000's.
... do you think there's any place left for a language for a language where you can inadvertently wreak havoc if you forget to write a copy constructor when you use a list, or forget to create a virtual destructor for a derived class, or a million other subtleties that so many developers don't even have a clue about?
As I said in another post, C++ has the advantage that it supports pointer arithmetic. Pointer arithmetic makes it easier to work at a low level, giving direct access to memory, which is useful for Operating Systems, database management programs, or anywhere that the exact memory location is useful.
Paul Santa Maria wrote:I don't think there's any question that C++ was a dominant force throughout the MS Windows era of the 1990's and early 2000's.
No. AFAIK from as early as 1994, the dominant languages for application development in Windows at that time was VB, PowerBuilder, VFP, Delphi. C++ was only used for systems-level Windows development then... and now.
How would you write an operating system with any of these? Or a compiler? Or a database engine? You are conflating application development (and very high-level application development) with systems development. The enterprise is just but a sector of the software development market. It doesn't even constitute the majority of deployed systems out there.
Paul Santa Maria wrote:... do you think there's any place left for a language for a language where you can inadvertently wreak havoc if you forget to write a copy constructor when you use a list, or forget to create a virtual destructor for a derived class, or a million other subtleties that so many developers don't even have a clue about?
I think that's a loaded question robbed from much of its objectivity. Many of those gotchas have to do with specific features required for both 1) systems development, and 2) interfacing with C libraries.
Secondly, it's not like Java does not have it's gotchas (making the original assertion less objective.) Man, I made a living for quite a while just cleaning up Java code left by *Java* developers who didn't know about them. A garbage collector is the greatest thing for application development, but unfortunately, way too many developers completely forget how to write apps for it, completely oblivious that Java does not have proper destructors (finalizers are useless and downright dangerous), leading this to database connections and sockets being left in GC limbo until they get reclaimed, if at all.
C++ has many subtleties that many developers don't have a clue about. And Java has many subtleties that many developers don't have a clue about either. But that's the fault of the developer, not the language. It always is.
So it does not make any sense to make that kind of language evaluation since it is the developer's job to know about them. Just as there are guidelines for coding in Java (think "Effective Java" and "Java Gotcha" books), the same exist for C++, and any developer worth his salt (be it Java or C++) abide by them.
One would hope that people should be aware there is a lot more development going on outside of the enterprise/web arena. Operating systems, file systems, database engines, device drivers... not to mention that the number of embedded systems running in PIC or AVR chips (think thermometers, microwave controllers, car computers, etc) far outnumber the number of enterprise/web deployments. So the answer is no: we don't see a demise of the "C++ era" (or the "C era" for that matter.)
Why people completely forget this is strange to me. Not trying to be derisive, but I think it is extremely detrimental to not be aware of the entire landscape of computing and software engineering. C and C++ have not been used for widespread application development for the last decade or so, and that is true. In fact, it would be crazy to do so since we now have application-level languages that are much better for that type of tasks.
But to extrapolate the relevance (or lack thereof) of C++ from the point of view of (very high-level) application development does not make any sense.
Imagine an embedded developer that has not done anything but C programming in little 8-bit PIC CPUs (which are pretty much the most widespread deployed type of systems in the world) asking whether Java is relevant since he cannot use the later to program the former. It would be absolutely strange, if not non-nonsensical.
Paul Santa Maria
Joined: Feb 24, 2004
Thank you both! I was deliberately being contrarian - but I honestly think there's at least a kernel of truth in what I was suggesting.
Campbell Ritchie -
Luis Espinal -
How would you write an operating system with any of these? Or a compiler? Or a database engine? You are conflating application development (and very high-level application development) with systems development.
I'd much rather use C
I believe that C (in contrast to C++) *does* continue to have a long and thriving future.
It's interesting to look at the Tiobe index. Which, by the way, has always - and continues - to give C++ very high marks:
The COBOL era ended quite a few years ago, but nevertheless there are millions of lines of COBOL code in production, and in some cases being maintained, today. Perhaps the same is true of C++, or perhaps C++ applications have a shorter shelf-life so that the end of the C++ era will be faster than the end of the COBOL era -- anybody want to speculate about that?
Joined: Oct 13, 2005
Paul Clapham wrote: . . . there are millions of lines of COBOL code in production, and in some cases being maintained, today. . . .
. . . so learning COBOL to maintain this stuff is a good way to earn money :wink:
@Paul : Whereas your arguement is persuasive, C++ might get into oblivion for most application programmers, but not so for systems and UI programmers. New gadgets of every Dev. system typically use C++ or a superset to build everything from IDE's to paint canvases.
@ Ritchie: Maintenance pays-off the individual or the organization when the cost of maintenance < cost of innovation, and in that sense I think Luis and Paul have a point...may not be long...not definitely 60 years like COBOL, guess modern langauges have lesser of that lifetime luxury! Bjarne I guess however will work overtime with the ISO committee to keep c++ live & lively for long.
Java Pal - Your friend in technology and innovation...India.
Joined: Oct 13, 2005
The cost of maintenance is usually less than the cost of replacement, because part of the cost of replacement is the risk of the application being out of use for a prolonged period. Many companies prefer to live with very old code, rather than risk changing to newer code, because of the risk of losing business while the system is being upgraded. Also, the cost of maintenance can be spread out throughout the year more easily than repacement.
If that weren't so, all COBOL, FORTRAN and LISP code would have been superseded decades ago, but they are still there on Tiobe. FORTRAN and COBOL are significantly lower than 5 years ago, but LISP maintains its popularity.
C and C++ remain high on Tiobe.
Wow, the posts on this thread have been brilliant! So much has been brilliantly stated here, I will only add my 2 cents... yes, Java, C#, and the rest certainly have their place. But C++ is not going away because there is a great deal of legacy code in C++ that still needs to be maintained.
And yes, Java, C#, and even VB.Net add some slick features such as automatic garbage collection, range checking for indexes, and so on. But as has been pointed out, these languages sometimes come with their own "gotchas."
Finally I will add that most of the aforementioned languages (except for VB.Net) are all part of the C family of languages. What this means is: if you learn one, you are in much better shape to learn another, since the basic grammar/syntax is on many, many points the same. It is similar to this analogy: if you know Latin or French, then learning Spanish or Italian should be a snap, and vice-versa, even though there are important differences you have to keep in mind. But good linguists do this easily.
C/C++ is certainly not going away. Embedded systems thrive on C/C++ and cannot even think of migrating to languages like java or c# this early, atleast the bit i have seen yet. Specially because the speed and the memory management power they give you, atleast c/c++ is not moving away from embedded systems.
Joined: Sep 09, 2011
I agree with the last post. The combination of so much legacy code -- and the inability in some cases to move to an embedded system (due to issues of speed, size, efficiency) -- mean that C++ is not going away.