What would it take for people to move away from C++?

Question

Even most people who like C++ admit that it has tons of warts not related to its niche as a systems/performance programming language. These include its antiquated module management system (header files), requirement for forward declarations, syntax quirks that make its grammar undecidable (such as <> angle brackets for template declaration), the inclusion of macros that operate at the textual level instead of real language features to address the things macros are used for, duplication of functionality like arrays and strings (STL and C versions of these types), virtually no syntactic sugar, and a general lack of modern features such as threading, garbage collection, delegates/closures, etc. (Note: Yes, in very memory constrained or realtime environments you might have good reasons for not wanting garbage collection, but it could easily be made opt-out and be the default way of managing memory.)

On the other hand, C++ is the only mainstream language that lets you write code efficiently and close to the metal, but also provides at least some high-level abstraction. It is mature, standardized and has tons of compiler implementations and libraries and a large legacy codebase.

To those of you out there that use C++ as their main language, what has made you personally decide that its warts are worth putting up with? What would it take to make you change your mind and decide to use a newer language with fewer of these kinds of warts? Do you use C++ because you really like it, or do you use it grudgingly because of legacy issues or because no other mature, mainstream language exists for its niche?

Answer 1

My opinion is that people need higher level languages that would somehow offer the same power C++ offers. Doing something in a high level language ( let's say Java ) while performing with better speed, native binary compilation, and other features, without resorting to something like JNI, would be "what I need to move away from C++".

Answer 2

Part of your question has a faulty assumption. You assume that we have a choice of language. In all of the projects I work on which use C++, there is no real choice. It's projects that have existed since long before I joined the company and were written in C++. They have many years of history behind them and a corresponding amount of code.

I think this is the biggest mistake people make when they say "C++ will die" or "why do people still use C++?". I definitely agree that, with the exception of system level programs, you aren't going to see many/any new projects starting in C++. IMHO, it doesn't make a whole lot of sense. Not necessarily because of inherent faults in the language but it's increasingly harder to find people who are any good at coding C++.

What people often forget to consider are the millions (billions?) of lines of C++ that are running our world today. Switching to a different language is extremely costly and cannot be done on a whim. It takes a huge justification to put the time and effort into rewriting applications of that size. This is why C++ won't die. At least anytime soon.

Answer 3

I use C++ (and have done so for nearly 25 years) because it is the best systems programming language around. I would say I don't recognise any of the so-called "warts" you describe - those are features!

For non-systems programming, I use other languages, such as PHP, Delphi, bash scripts, awk, perl and Smalltalk. One size does not fit all, unless you are some kind of language bigot of course.

Answer 4

Why? Do you stand to make a profit if I start writing code in a different language? :-P

All kidding aside, I write C++ code because that's why my employer pays me. It's really that simple. If they decided to use a different language, I'd start using it. Now, as to why they chose to use it, I can only speculate. My guess is that they have two primary reasons:

1. There's an ample supply of college graduates who are good enough at C++ that they can accomplish their business goals.
2. C++ offers good enough performance in real-time distributed systems.

Answer 5

It's unfortunate you haven't discovered the fundamental elegance and conceptual integrity of the language. It offers as much a comfortable and consistent view of the world as any other language, as reflected by its continuing usage over the years. YMMV, but allow us all the same consideration.

Answer 6

Yes, I enjoy C++ much more than Java - because I'm much more free to express myself.

C++ is necessary because it's the only truly scalable language at the moment. There's a way to tweak every aspect of the program so it never runs out of steam.

The other good thing is that the verbosity goes in the library code, not the "usage" code. Once the library is working the usage code is usually nice and terse (and easy to read if you did the library right).

In Java/C# all the verbosity is carried down to the usage code - try/catch/finally ... all these things need to be typed over and over and over again. Ick...!

Did I mention stack-based objects? How do people live without them...??

The only place C++ really falls down is in reflection (though even that can be sort-of done, eg. COM).

Yes a cleaned-up C++ with tighter syntax would be nice but we know it's never going to happen. You can get used to the syntax and overall it's a small price to pay for what you get in return.

Answer 7

Frankly, it works well and I'm paid to write it. It isn't tangled up with the marketing whims of a single vendor that controls it. Fewer and fewer C++ experts are on the market so my value is increasing over time. I'll continue to use it until the market becomes unsustainable.

Answer 8

When a new language is able to be as expressive as C++ is. Because of conflict of interest between high and low level capabilities this is tough to attain. Which is why we have language and process interoperability in the first place.

In addition C this is probably tougher to do with C because is so lean and powerful. C wins in the low level arena because of this. And C creates a good backing for C++ and objective C.

In short you'll still be seeing C and C++ for a long time.

Answer 9

Give me a programming language that:

1. is standardized and not driven by a single company
2. is not bound to one platform (not only in theory)
3. compiles to native code
4. gives me the same amount of efficiency as C++
5. provides a very well-thought-out standard library
6. has at least one mature implementation for various important platforms

...and I might consider switching ;-)

Answer 10

C++0x!

Answer 11

As you described, C++ certainly has its warts, with this C++ FQA doing a good job in pointing many of them out. However, people and organizations that have been using a language for quite a while have encompassed a large number of idioms, gotchas and guidelines that make working in it more bearable. The style of programming in C++ has also evolved over the years. With native compilation and mature tool set, on many platforms, C++ is still a tough contender.

The only way for C++ to lose its' place rapidly, in my opinion, is for a major company, like IBM or Google, to stand behind a viable alternative, like the D language, and push it with all its might. But, that is practically impossible to happen given the sheer amount of already existing C++ in their own codebases.

Answer 12

These include its antiquated module management system (header files)

I can't really see any problems with the way C++ uses header files. By giving two ways to include headers, you can specify at the source level whether symbols should come from your application or from the system's installed facuilities. All modern C++ compilers support precompiled headers, so there is no performance penalty. Separating headers from implementations allows developers to use libraries programmed in other languages.

syntax quirks that make its grammar undecidable (such as <> angle brackets for template declaration), virtually no syntactic sugar,

The language is very large and can be difficult to completely follow, but it is still guided by a number of logical rules that apply everywhere. The language actually provides many ways to customize your use, through function and operator overloads and with templates that make it possible to give a concise expression of your problem

the inclusion of macros that operate at the textual level instead of real language features to address the things macros are used for,

There's a lot not to like about the preprocessor, but it can be very useful to operate on the tokens, from the point of view of code generation. Granted, things like M4 macros provide a much more powerful way of doing this, but the downside is that it's not a standard part of the language. The standard c/c++ preprocessor is available EVERYWHERE the compiler is.

duplication of functionality like arrays and strings (STL and C versions of these types)

This functionality is not duplication. Low level, byte by byte primitives (uncluding pointer arithmatic) is needed for implementing higher order concepts like generic containers. Remember C++ is for programming the systems it is implented on, but also for providing the expressive power to do real work.

and a general lack of modern features such as threading, garbage collection, delegates/closures, etc. (Note: Yes, in very memory constrained or realtime environments you might have good reasons for not wanting garbage collection, but it could easily be made opt-out and be the default way of managing memory.)

Threading is something that requires cooperation from the operating system in a way that a programming language cannot really standardize. Many languages abstract this into a single interface, but this has not happened in c++ (this is coming, apparently). Garbage collectors are available for C++, but it provides a more powerful concept, RAII. Opting Out isn't the C++ way anyhow, if a garbage collecting facility is ever standardized into the language, it is certain to be an opt-in, so that you don't have to pay for it if you aren't using it.

Answer 13

its niche as a systems/performance programming language

It's a pretty big niche! Chances are that if a piece of software has over 10 million users it's written in C++:

• Windows
• IE
• PhotoShop
• Firefox
• Office
• SQL Server
• MySQL
• Google Search Engine
• AutoDesk

Source: http://www.research.att.com/~bs/applications.html

Answer 14

The best way to understand why C++ is the way it is, and to appreciate it's accomplishments, is to read "The Design and Evolution of C++".

For all of its warts, C++ is a pretty dang good language.

Answer 15

I mainly use C++ for embedded platforms which ussually requires a lot of close interaction with the hardware. I don't really see any OO-substitute here. If I were to substitute C++ for anything here, it would be something that could resolve all the include-perks at compile time so I didnt have to worry about those.. Basically, something that could ease up my development, but didnt provide any runtime overhead (reflection, garbage-collection and the likes).

For me C++ is all about runtime performance and absolute control. No fancy-pancy runtime stuff that works "behind-the-scenes".

Answer 16

I do scientific computations, where my GUI is in C# and my backend is C++. Its not out of the realm of possibility that C# could at least equal C++ in terms of performance, but thats not where the focus of the C#/insert managed language here groups. It would be difficult, but well within the realm of possibility to have C# perform as well as C++ (or very close to it) for numerical calculation, as the IL is compiled down to machine code. If/When that happens, I'll gladly make the switch.

Answer 17

When they come up with a language that runs faster in less memory and is more widely supported.

Answer 18

For me, I prefer C++ because:

• It's still a reasonably straight-forward representation of what the hardware is going to do, or close enough that you can make educated deductions about actual program behavior and performance
• It's flexible enough to allow me to use or implement most programming paradigms
• It has high compatibility with other libraries and modules, and the largest existing support base of reference and directly usable code
• Most of the "warts" are easy to eliminate with good programming practices and/or utility libraries, as opposed to other languages where "warts" are less fixable (eg: you can easily fix memory leaks by using smart pointers, and easily diagnose memory corruption with direct memory analysis, you cannot easily debug memory corruption problems in a higher level language like C#, and yes I've had them)
• C++ apps can generally be made to run on any OS versions with the only limitation being effort; higher level languages typically require runtimes which may or may not be present

What would it take for me to prefer something else for main development? Well, in addition to addressing the above reasons in some manner, the other "higher-level" language would have to convey the feeling that I would still be able to implement and debug everything I can do in C++. Really the only thing which has come close for me is C++/CLI, but it's syntactically even worse, harder to understand, and fails the "runtime required" test (and arguably doesn't add much in terms of the other desired benefits).

I'd guess in the next 30+ years before I retire, I'll be paid to write something other than C++. There are certainly development areas where C++ isn't preferable, and strong motivations for language vendors to force developers into higher-level languages running on proprietary and/or vendor-controlled runtimes (eg: Java, C#, etc.). For now, though, for me, C++ is still the right tool for the job, and I enjoy getting paid to keep writing it. :)

Answer 19

You are going about this the other way around. People choose problem/application domains they are interested in. The choice of language follows from that decision and is quite trivial.

Nobody chooses a programming language. Programming languages by themselves are boring and talking about them without reference to a problem/application domain is absurd.

Personally, I wanted to work in machine learning. As a grad. student I worked on analyzing graph representations of huge datasets (IMDB, Netflix). I used C++ for most of my work. I would have loved to work in C# or Java or better yet Python but the nature of the problem required me to use C++. Over a period of 5 years I have fallen in love with C++ for the golden balance it achieves between efficiency and abstraction. I will use C++ whenever I see the need for it. C++ programmers are hard nosed pragmatists who will not let anything stand in the way of getting things done. They will not cling to C++ just for the heck of it.

Answer 20

My personal choice to use C++ (when I even have a choice) is because it is one of the only multi-purpose programming languages that is not interpreted and has enough "bells and whistles" to let me get things done relatively quickly. Now there are a bunch of reasons that I choose other languages (e.g., Python, Java, Perl, ksh, etc.) when the opportunity presents itself. I use other languages for "one-off" applications and scripts where performance is not an issue and neither is "field deployability". The deployment support for many scripting languages is very web-centric and I work in more of an infrastructure and "invisible glue" industry right now. We are looking J2EE application servers to help out with deployment and support concerns but we already have some nice methods for executable services.

The biggest reason that I will continue to use C++ by choice in many cases is that it has support for almost everything I need after you add a select few libraries in to handle non programming language platform stuff (threads, sockets, etc.). And ... Yes ... I do consider threads something that should be represented outside of the programming language. That is the main reason that I tend away from other languages -- I actually like languages with a bare bones core where functionality is provided via add-on libraries.

Let the programming language worry about syntax, inheritance, polymorphism, module structure, exception handling, looping constructs and the like. Once you enter the application domain and want to multithread your applications or maybe use multiple processes instead, then you are talking about libraries. Too many languages try to force a particular programming paradigm (OOP) that is not applicable to every problem. I prefer a nice general purpose programming language.

The last reason is that I choose C++ over other languages is that I actually think that it is more deterministic than other languages. I know that Java is the platform neutral solution of choice and Ruby & Python are the rapid development alternatives du'jour. The problem is that applications that are interpreted always perform at the whim of their interpreter. This isn't always a Bad Thing and it most certainly isn't always a Good Thing either.

Chances are that C++ is going to be here for a little while longer. My guess is that a large number of the purer OOP languages will start to loose market share to more general purpose dynamic languages (probably Ruby and Python) and that those languages will pick up some more serious OO chops as well. I'll switch to another language when the sun starts to really set on C++ and there is another language that is well accepted by the "industry". I'm sure that it will happen some day... after all C++ actually replaced C as my language of choice a number of years ago.

Answer 21

I take it as accepted that the high-level and low-level parts of a project don't need to be (and generally shouldn't be) written in the same language these days. So you're either waiting for employers to realise that even though it's harder to find devs to work in multiple languages, it's actually easier to find good devs, or waiting for the army of incompetents to get with the polyglot program.

Answer 22

C++ is a tool in my toolbox. So is java and python and a few other things.

Handily my company's environment enables me to use whatever is appropriate.

• C++ == perf when necessary.
• Java == when perf is not so necessary (due to the fact that the network/external IO vastly outweighs CPU cycles), and speed of development is necessary.

Tools in your toolbox. Use what's appropriate.

Answer 23

Reviewing your list of the "problems" with C++, the only one I might come close to agreeing is a problem is the STL/C string conversions.

I might ask, why are you wanting C++ to be C#?

Answer 24

C !!man .... why so oops.