Learning a language is all about your goals. Do you want to work in a domain where execution time is the most important factor, even more than developer time? Games, finance, system software, etc often use C++ because speed and control over memory usage far outweighs the benefits of faster development time in other languages.
My main interest lies in game development. To be a little more precise in game engine development. I'm studying computer science at the moment and I plan to work towards such a job after graduation.
And afaik most game engines are written in C++ because of performance and memory management.
Have you read the source some modern game engines? Doom 3 is an interesting example (a bit old now, of course) because it's not particularly C++-like; IIRC from the last time I looked at it, C99 would do effectively everything it needs. This is not uncommon in the game industry.
The game industry uses C++ because most of it is consistently about ten years behind the rest of the industry (remember how long it took them to switch from asm to C? and then from C to C++) -- the charitable viewpoint for this is that the industry is conservative; this is also a consequence of the toolset in the embedded world.
Any natively-compiled language with a good compiler will produce pretty fast code without too much work, but to get really fast code in any language, you really need to know what the compiler is doing and be able to tweak it from the language; writing really fast code in C++ requires about as much work and as much thought (but less knowledge of your target compiler and runtime) as writing really fast code in Common Lisp or Scheme.
It's important to note that it's actually easier to write slow code in C++ than in C if you're not careful; C++'s powerful abstractions cut both ways. Unless you explicitly forbid a number features, C++ takes away your ability to look at an isolated block of code and get an approximate "in-head" assembly of it.
All that said, if you want to work in the game industry, you need to learn C++, you have no choice. But at the same time, you could be experimenting with building games in newer languages like D, Rust, and maybe more exotic choices like SML using MLton or Gambit Scheme (maybe using Stalin for a final pass).
C++11 is a vast improvement, for me, over earlier versions of the language. I still think it's a mess of a language, and the usual caveat applies (no one knows all of C++ well -- know what subset you're using and be aware of what you don't know), but it can't be dismissed.
Should you learn it? There's still a ton of software written in it and it has one of the best compiler ecosystems; for many applications it's one of the only practical options for a production system. Every programmer should know enough C++ to understand templates, RAII, operator overloading, things like that, if only to compare with approaches in other languages.
Should you build new systems in it? I would avoid it if possible, but once you learn the language, hey, maybe you'll love it. And if so, there's no shortage of C++ programmers to work with you.
I think this sentence embodies the biggest problem with C++:
"...abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with no overhead compared to hand-crafted code."
This is superficially similar to the Lisp community's "sufficiently advanced compiler," but in C++ it really means that high-level features are thoroughly undermined by low-level concerns (as opposed to just being slow until better compilers come along). Other languages seem to get high-level abstractions right, in the sense of exchanging a constant-factor loss in performance for a large gain in programmer productivity.
Better than C#? Better than Python? I think your definition of "mainstream" might be a little narrow, or else you have a very odd understanding of what makes a good high-level abstraction.
Also, why limit ourselves to "mainstream" languages? Once upon a time C++ was not mainstream. Why should we shy away from Lisp, OCaml, or Haskell just because they are not popular? In every discussion about C++ and its technical ups and downs, someone points to its popularity, as if that were some kind of justification. The history of computers is overrun with examples of popular-but-inferior technology.
Yes, better than C#, and waaay better than Python. Similar to but slightly better than Haskell, too. I don't know about OCaml.
(edit: C++'s main deficiency against C# and Python is its lack of a reflection system. Against Haskell, C++ is well known for being similar, but templates in C++ are more flexible and less constraining than Haskell's type system features -- for example if you want to overload + you don't have to buy into the entire Num typeclass.)
I would say that the lack of a standard garbage collector ("smart" pointers do not count since programmers must manually break cycles and decide among smart pointer types) is a pretty serious deficiency. I would also point to the abysmal error-handling support in C++; you do not even get a reliable way to report errors that occur in destructors.
Really though, my big issue with C++ is that the high-level features are bogged down by low-level details -- if I wanted to deal with low-level details I would not be using high-level features in the first place. Why should I have to manually determine how to capture variables in a lexical closure? Why should I have to manually declare "virtual" inheritance to deal with the multiple inheritance diamond? Why are destructors not virtual by default? Why are string literals still pointers to character arrays, why are arrays still not bounds-checked, why are integers still fixed-width (and why are integer overflows not reported as errors?)? Yes, these things all make sense sometimes but in most cases they are the opposite of what you want -- you should have to write more code to get this behavior than to avoid it.
Well, I agree with your complaints about the annoyance of lacking garbage collection, but not everything you complain about. The only nit I really disagree with you on in this post is that it's certainly reasonable that you should have to manually determine how to capture variables in a closure, in C++, because of the nature of the language. Also, many other languages avoid the multiple inheritance diamond simply by not allowing multiple inheritance (and others do it a bit better). The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language). But I'm not claiming that C++ is less annoying to use. I'm saying it has better facilities for making high-level abstractions. That's because of its type system, and you have to go to something like Scala, Haskell, or other statically typed languages, or maybe something homoiconic like Lisp, or something odd like Oz, to really beat. You can make better, more accurate abstractions in C++ than in other mainstream languages, and they're safe and solid, while in languages like C# you often end up having to resort to unsafe conversions.
"The only nit I really disagree with you on in this post is that it's certainly reasonable that you should have to manually determine how to capture variables in a closure, in C++, because of the nature of the language"
I disagree here. First, the nature of the language is no excuse -- I am criticizing the nature of the language to begin with. Second, in this case, there is a sensible default: always capture by value. If you need or want to capture by reference, create a reference and capture that -- which is already what people have to do when they return a closure and use smart pointers to maintain the lexical environment.
"The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language)."
Except C++ does not maintain compatibility with C, and "performance" is not an excuse either. If performance is a concern, create a keyword to disable default behavior; e.g. if you want to not have a particular destructor be virtual, then there should be a keyword for that. Even compatibility with C is not an excuse -- already the extern "C" syntax is used to disable the name mangler, so why not go all the way and have it also disable things like array bounds checking and creating string objects for string literals?
Basically, C++ is a language that makes unsafe code easier to write than safe code; this is the opposite of what a high-level language should do.
That is a typical trade-off for high-level features: you incur a (constant factor) performance penalty to gain programmer productivity. If you need to avoid performance hits wherever possible, the language should give you an escape hatch; default behavior should make developing reliable software easier, not harder.
I don't understand your point. C++ does not have the ability to manipulate syntax trees as data the way Lisp does, for example, making it strictly less "powerful" in terms of abstraction. (Templates, though turing complete, aren't what I mean here)
Edit: Also, I don't know much about Lisp, despite being a bit of a Scheme weenie in the past. When I try to think about whether I'd like to implement some hypothetical project in Lisp or C++, the most important difference between them seems to be garbage collection. It's more realistic to ask whether I'd rather use Lisp vs. Java, or Lisp vs. Scala, or Lisp vs. C# or Python or Ruby, than C++, because garbage collection is a big issue that makes it difficult to compare them by some notion of how it would feel to use the languages.
I have a hard time evaluating whether macros are really that useful. Whenever I see people give examples of using macros, usually it's just superfluous, something that could be done a bit more verbosely without macros in a language like Python or Ruby, or done a bit superiorly in something like Haskell. And if it were a situation where macros were very useful, all I can think then is (now let's pull some anti-macro tropes out of the hat!) how debuggable is this? And would it really be that hard to solve the same problem in one of the other languages?
Have you looked at Boost.Proto? You can in principle manipulate syntax trees in any way you like, but you'll have to spice things up a little to fit with operator overloading.
No; learn C, because there is a lot of C code out there, and then learn a high-level language like Haskell, Lisp, OCaml or Python. C++ is only worth knowing if you need to maintain legacy code; if you are writing new code you should steer clear of it.
Yeah, I'm sure that Clang, the new compiler that everybody is so fond of, is "legacy code".
Oh yeah, let's put Chromium, Firefox, and all of KDE on that list too.
As a person who is proficient in both C and C++, I find this constant war ridiculous. Neither languages are obsolete ok? Which one is best for you depends on the circumstances. Stop speaking in absolutes.
I know people argue that it's not exactly the same, but isn't standards-compliant C accepted in C++ anyways? Why make the distinction if you're going to use a subset anyways.
As long as we're taste testing paradigms, second on the totem pole has got to functional. Can you support why the OP should look at constraint programming, or do you just wish more people would?
"I am already familiar with C, as well as Python, Go, Java and a few other scripting languages."
In terms of relevance in the real world, those languages cover pretty much all bases. The only reason I can see for learning more languages would be to learn entirely new ways to think about programming i.e. different paradigms. Functional programming is fine as far as that goes, but constraint programming is even more radically different (it is not likely to be viewed as simply a "style" of programming that can be used in C or Python), so I mentioned it.
To directly answer your question then: Yes. C++ is certainly something you should learn.
Now only you will truly know if C++ is suitable for the tasks you do but unless you work at a university then chances are C++ will be good to great for whatever you need.
I tend to write a lot of systems-level code, and the reason I choose C++ over C is because C++ gives me more power to build useful abstractions, while still letting me drop down to the bit-twiddling level if I need to. I do enjoy high level languages (in particular Haskell) but C++ is still the king on my servers.
Python yes as it is helpful in many different places but Haskell and OCaml?! I know this is HN but these languages are pretty niche and only really used to any serious degree within academia. C++ is still one of the most flexible languages for application development on every major platform and with C++11 it has had a massive resurgence. Compare how things were a few years ago to the massive amounts of work places like Microsoft are putting into their C++ technology offerings. Visual Studio 6 all the way to Visual Studio 2010 had god awful C++ support outside of what Microsoft wanted to offer. With 2012 and now 2013 things are a hell of a lot better. Check out Microsoft's GoingNative 2013 stuff.
As for C it is a great language but it is pretty much only for either old stuff or system level stuff. In the real world I see people pick C++ over C if possible.
The point is, C is worth learning because of what it teaches you. Likewise Haskell and OCaml are worth learning because they'll make you a better programmer. C++ is only worth learning if you're looking for a career in the gaming industry and therefore need to know it to get a job. C++ is a terrible language that does pretty much everything wrong. The fact that it's only with C++11 that the language starts to become bearable should tell you something. Learning C++ will not make you a better programmer, it will make you a more employable programmer, although even there something like Java or PHP will make you a even more employable programmer.
If you're doing any embedded programming you're going to be using C. C++ is pretty much exclusively used in the gaming industry, and there mostly because of historical reasons more than anything else (all the popular frameworks are written in C++).
> C++ is pretty much exclusively used in the gaming industry
I'm curious how you've come to that conclusion? C++ is used in most of the major web browsers, most of the major database engines, most of the major office program suites, it's widely used at Adobe, Microsoft and Google... C++ is in the top 5 of most language popularity rankings (TIOBE, langpop).
Sure, C++ has its issues, but claiming it's only used in one industry is way off base.
Most new development isn't done in C++, all the things you're referencing are primarily legacy applications (legacy in the sense that they were originally written a long time ago, not deprecated). Most new software even at the companies you list isn't written in C++. MS for instance has thrown their weight behind C# as their go to language. Google among many things has Go to replace most of the things they used to use C++ for. I don't have any insight on Adobes usage, although I do know that most of their dev tools are built on top of Eclipse which is JVM based.
As for office suites, there's three of them out there, MS, which is C#, Apples which is ObjectiveC, and LibreOffice which so far as I know is Java.
I wouldn't be entirely surprised if a lot of the DB engines are done in C++, but I also would expect quite a few of them to be done in C as well. DB engine is a rather specialized area that demands the best performance you can possibly achieve, so something low level like C or C++ is to be expected. In order to achieve top performance you need to sacrifice ease of use so a really basic language like C or C++ is expected.
Interestingly enough looking at the source code for Firefox there is indeed some C++, but there's actually a lot more JavaScript in the Firefox source tree than there is C++.
Microsoft's Office suite is primarily C++. There was an attempt to start using more C# a couple years ago, but it's still mostly C++.
On a closed-source project, it's hard to get the details. But the open source projects, however, we can get a very clear picture.
OpenOffice: [1]
10.4 million lines of C++
1.2 million lines of Java
*edit* noticed you mentioned LibreOffice, not OpenOffice
LibreOffice: [2]
5.7 million lines of C++
0.4 million lines of Java
Firefox: [3]
4.0 million lines of C++
1.8 million lines of C
1.7 million lines of javascript
MySql: [4]
7.0 million lines of C++
4.0 million lines of C
0.4 million lines of javascript
0.3 million lines of Java
The point I'm trying to make is that C++ is widely used, and definitely not used just for gaming.
> Most new development isn't done in C++
Whether or not C++ is the right choice for new development is a different question. Github posted their top 20 languages for new repositories in 2013 [5]. C++ is #6 and has more new projects than C, Objective-C and C#. Even if it's fading in popularity, that's still a lot of new projects in C++.
Most new development at Google still uses C++ (or Java). Go has been making inroads, but it is still largely used by early-adopters or small intranet or prototype applications.
Source: I work at Google and use all the languages in use at the company (including both C++ and Go) on a daily basis.
I agree C and Haskell are both worth learning as they will teach you a lot of should make you a better programmer due to the different point of view they give you towards development however this question was if learning C++ was worth learning.
The answer to that question, IMHO, is yes which is what the OP wanted to know. Had they asked what languages they should learn I would put other languages above C++ but that wasn't their question :)
"Haskell and OCaml?! I know this is HN but these languages are pretty niche and only really used to any serious degree within academia"
Maybe so, but the programmers I know who have switched from C++ to Haskell/OCaml/F# never seem to regret it. They are getting more done in less time, and spending a greater fraction of their time writing good software than tracking down annoying low-level bugs. The small trade-off in performance does not seem to be an issue, and in the few places where it is, some C or assembly code invoked via an FFI solves the problem.
"C++ is still one of the most flexible languages for application development"
Only if you are not counting the overhead of actually getting a complex C++ application to work reliably. Even the new abstractions in C++11 and C++14 seem to force programmers to deal with low-level issues than in almost every case are a distraction from the high-level problem being solved.
Nope, can't do it unless you strip out things that are inherently C++. C++ does too many things "for the programmer's benefit" to allow it to fill the domains that C is good at. They are different languages with different benefits.
> Nope, can't do it unless you strip out things that are inherently C++
It's likely that your idea of what is 'inherent' to C++ is just wrong. First of all, C++ is almost a superset of common C so, yes, it can can really replace C entirely and completely. Whatever grievances you have with the language don't change the reality that even embedded code benefits from, and has been gaining ground in, C++ for quite some time.
In any case, I'm not arguing C++ is inherently 'better' than C. I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical.
"I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical."
We do still have a need for a low-level language; C is not the greatest language but it gets the job done. There is also quite a bit of C code out there, proof-of-concept code, reference implementations, etc., and so not knowing C means being cut off from all of that. C++ is not as commonly used for such things, or if it is then only a minimum subset of it is used, and it has no advantage over C as a low-level language. The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction; this has not changed with C++11 and it does not look like it will change with C++14.
So really, the only good reason to be learning C++ in this day and age is if you need to extend or maintain some part of the massive body of already-written C++ code. In other words, if you need to deal with legacy code.
You seem to think I'm dismissing C. What I'm really trying to express is that I'd recommend people learn C++ and consider C an old-school 1980s, unsafe, rather laborious, subset of it.
> We do still have a need for a low-level language
C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?
> There is also quite a bit of C code out there... not knowing C means being cut off from all of that.
I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy.
> The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction
Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?
Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible".
On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.
If you need C you should write C. If you don't need C, you should write in something nice, I.E. not C++. Why sacrifice ease of use 90% of the time in order to gain access to low level features 10% of the time? Any high level language worth anything has the ability to call C code via some mechanism (some better than others, Java probably has the worst mechanism out of any high level language). Use two languages that work really well at what they do, rather than one that sucks equally at both.
I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?
I agree. I have touched Java, C#, Clean, very little of Haskell, VB.net, PHP (currently main one). I did some small scripts in python, and only read about scala, but haven't really touched it yet.
I recently (about 2 years ago) started writing, on and off, a new IDE for Clean in C++ with Qt. No complaints. I somehow like it better than C# with all its drag and drop capabilites (yes Qt has that also). However, somehow I like Qts way of doing it better...Don't know what I wanted to say with all this, I just prefer C++ and would choose it for applications. Unless demanded otherwise.
"C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?"
What I said was that C++ has no advantage over C as a low-level language. When you are writing low-level code you usually do not appreciate implicit function calls, extra data being allocated that you did not explicitly declare, name mangling, etc. Low-level C++ code is basically C with a slightly modified set of annoyances balanced by a small set of conveniences.
"Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?"
It is not about being slick and elegant, it is about being productive. The majority of applications are high-level, and the programmers who write those applications get more done when they use high-level languages.
Sure, sometimes an application needs to do a few low-level things. For some high-level languages that means using an FFI (e.g. JNI for Java). We could do better if we wanted; CMUCL and SBCL are Lisp implementations that do a fantastic job of separating high-level and low-level constructs, so that you would never know the low-level features existed if all you wrote was high-level code. With C++, you get something very different: high-level code is tangled up with low-level constructs, issues, and reasoning.
"I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible"."
Actually, I switched from C++ to Lisp after having programmed in C++ for more than a decade. This is not a decision I have any serious regrets about. With Lisp I am writing high-level code more easily, and what I am seeing is (a) better performance, (b) the ability to do more ambitious things, and (c) less time spent debugging. Sure, I have bugs in my Lisp code, but those are exclusively high-level bugs -- bugs in logic, bugs that I can fix without having to spend hours tracing pointers. In Lisp, I can report errors anywhere and not have to worry that my program will abort; in C++, sometimes errors just have to go unreported.
It is not that I had one bad experience with C++. I TA'd a data structures course that was taught in C++, and it was a nightmare that left the students with a poor understanding of basic data structures. I have spent countless hours debugging C++ code -- code I wrote, code others wrote, code written by gurus, code that is supposed to solve high-level problems, etc. My group almost missed an important deadline because of the time we had to spend getting C++ code to work. I have worked with people who refuse to even use C++ exceptions because of the all the problems they cause.
Really, I do not mean to rave about Lisp. It is a great language, but there are plenty of other great languages. I liked programming in F#, though I am not an expert in the language. I have seen people switch from C++ to Haskell without ever regretting their decision (including a number of people who said they would prototype their code in Haskell, then rewrite it in C++ when they needed better performance; the rewrites never happened).
"On another note, C++ is at least improving"
I found C++11 to be a disappointment, and C++14 is looking to be more of the same. C++11 contains lots of fixes to problems that are particular to C++, and those fixes introduce as many problems as they solve.
I was objecting to filling "all" the domains. I was referring to classes as inherently C++. For example, constructors, destructors, virtual functions, namespaces.
For example, AFAIK you cannot have a naked struct in C++. A struct is a class, and therefore can have methods, thus can have constructor and destructor.
Also, exceptions are a big part of C++ that I don't think you can remove?
If you want simple, obvious separation of data and logic, and you don't want exceptions or name mangling, then C is probably a better choice for that domain.
I like C++, but it is not C and is unlikely that one will ever replace the other in all the domains.
OTOH, if you want to write OO and you like C++, then it is not a bad choice.
I think both are being used to write new systems, so neither is legacy :-)
> I was referring to classes as inherently C++.
> AFAIK you cannot have a naked struct in C++
The "class" keyword and the "struct" keyword differ only in default member visibility. You're free to use the struct keyword. Yes, such structs can have member functions, but they change little except to act as a convenience. A "naked struct" in C++ is called a POD ("Plain Old Data") type, and there are a few rules to ensure your structure meets that definition. The standard library has a type trait to test a class/struct to see if it meets that definition (called std::is_pod).
> For example, constructors, destructors, virtual functions, namespaces.
None of these actually interfere with any use cases or domain that I can think of. Constructors and destructors are insanely valuable features, even if you use nothing else. Functions are not virtual by default and impose no overhead unless used.
> exceptions are a big part of C++ that I don't think you can remove?
You can turn exceptions off at the compiler level. -fno-exceptions in GCC and Clang. RTTI can also be disabled. Disabling both in embedded cases is perfectly reasonable.
> name mangling
extern "C" {} blocks kill name mangling and allow you to export a C API and ABI compatible function.
Your question is probably driven by the fact there are a lot of languages which allow you a greater level of abstraction.
The answer is "it depends" (of course!). If you plan to hack into some kernel source code, device drivers, legacy software, or high performance softwares, probably it's worthy.
My advice is: once you learned one language for each type (functional, procedural, object oriented) and a scripting language (python, perl, ruby, ...), then get a project and learn while hacking.
At least from what I can gather from Pascal's Showstopper (the book on the development of Windows NT), that was against Dave Cutler's wishes, and indeed the main kernel was originally just C; that books documents some of the hassles they have as a consequence of using C++. (And indeed, it strikes me as bizarre that one would use C++ for an OS kernel.)
C++ is one of the few (maybe the only) languages that gives you enough high-level features to be productive, but doesn't do so at the expensive of ruthless runtime efficiency. If you need to squeeze every ounce of juice out of a machine, but still require the ability to create good abstractions, C++ is for you.
Honestly, for me I get way more use out of a mix of C and Java. If I'm writing something complex enough that C++ is helpfully, usually I don't have as an extreme performance restraint. When I do have serious restraints, C has never done me wrong. Usually when I do something in C++ I look back at it and think it would have been easier in either C or a higher level language.
With this said, that's just me and the way the world has worked for me. There are tons of applications were C++ is the right answer and C could never fill the bill. If you just want to learn native and low level programming, learn C instead. Its simpler, easier to learn and has more use cases(Linux kernel, some OS-less micro-controllers)
So to answer your question, "ehhh... sure. maybe?"
As the others are saying, it very much depends on what you're trying to accomplish. I'll start off by saying that C is a much, much simpler language than C++ and unless you're looking to make a serious investment it might be better to just learn C, even though C++ adds a lot of genuinely useful stuff.
You might consider learning C{,++} if:
If you need to interface with hardware at a very low level, such as when you are programming a microcontroller or writing a device driver.
You have a reasonably small application and you need the best performance possible. Don't use them because "C++ is fast". C++ is fairly fast by default, but so are many other languages where it's harder to shoot your foot off. Use C or C++ because of the greater scope for optimization in memory layout and other sorts of painstaking optimizations.
Learn it because you want to create a library that can be used by many other different languages. Pretty much any language has some method of calling a C function, it's pretty simple. Making calls between languages that have their own garbage collectors is more complicated.
Learn it to teach yourself about how your computer works. you could also use assembly language here, but C works well enough. Getting a sense for how other languages work under the covers can help you understand performance trade offs in other languages better.
Just saying: if you know C and Java (as you mentioned), then C++ is just a matter of syntax. It won't introduce any new concept nor will make you a better programmer. I wouldn't really consider learning it unless you have to use it in any specific context or project. There are so many new, different and more innovative languages out there on which i'd focus.
is COBOL still worth learning ? without context , your question is meaningless. I know engineers that make 6 figures salaries maintaining COBOL systems. So it is worth for them and they dont care about hype.
give some context.
"Is C++ still worth learning for this or that kind of job or field?" is the question you should have asked.
Now i would say most programming languages are still built on either C or C++, and a lot of them allow C or C++ extensions,even hipster's nodejs. You cant be an expert on these solutions/languages without knowing the lower level.
C++ is still worth learning. But if you can - try Go instead. Both solve more or less the same problems, but, Go has the advantage of being designed more recently - and so it has lesser cruft, well designed features, and its easier to learn and master.
1. You do any desktop programming. You will meet c++ along the line somewhere for certain, be it some win32 abstraction, Qt, Wx etc. I'm ignoring apple here for ref.
2. If you're writing high performance software (scientific computing, gaming, trading etc).
I can't really see many other use cases that can't be solved either via C or a high level language easily.
To be honest I really was indifferent about C++ for years but C++11 seems pretty good so far. I can see it creeping in places where JVM/CLR are being pushed a bit hard and in the systems programming space, but on the basis that some people like myself are still maintaining oooold c++ code, I can't see that being that soon.
That sounds like a red herring. Can C++ be easily compiled for heterogeneous architectures and distributed systems? Does it support massive concurrency in the Erlang/Go style? Is it easily and efficiently vectorizable the way that APL was once? Somehow I've always felt that C++ can do "anything" at the cost of "being equally bad at everything". Regarding C++11, I really like Rob Pike's comment on how the creators of C++ seem to think that the problem of pre-C++11-C++ was that "it apparently didn't have enough features".
Go's style is not the same thing as Erlang's style. And the answer is yes, if you're talking about Go's style. Your line about C++ not having enough features is cute-sounding but actually it's anti-intellectualism under the religion of minimalism.
Your line about C++ not having enough features is cute-sounding but actually it's anti-intellectualism under the religion of minimalism.
First of all, it's not my line, it's Rob Pike's line. Second, upon seeing how the C++ people intend to fix deficiencies of C++ by throwing even more features at it, it's very difficult to see it in any other way. Third, the only "anti-intellectualism" I see here is named C++: It's actually symptomatic of certain organizations that instead of trying to see the big picture and really fix things in a systematic way, they "anti-intellectually" hack and tweak and tinker and micro-optimize. For example, IBM has been doing that in the 1960s with their HW architectures before they got their shit mostly together, which is why the ACS project failed, only for it to be rediscovered forty years later, with modern CPUs finally (!) utilizing these ancient but very well working techniques, such as superscalar out-of-order design that will celebrate its fiftieth birthday in a few years. Now, the same breed of people who ditched ACS in the 1960s are apparently in charge of design of mainstream languages. I wonder if we'll survive the next decades in good mental health before enough people realize the same thing again, ditch that crap and start all over again.
I wouldn't. You can't build a solid structure on a broken foundation, and C++ is most definitely broken. Instead you throw it away and start fresh. The problem with C++ is it tried to combine the power of C with more advanced features while still maintaining all the low level access that C gives you. The problem with that is that it undermines all the advanced features by either allowing you to easily break them in odd ways through low level features, or else by leaking low level details all over your high level abstractions and requiring you to keep track of all those details the abstractions were meant to hide in the first place. If you want to see how to do a "low level" language better look at the approach that Rust, D and to a lesser extent Go, have taken. They borrowed from C where it made sense, and they threw away what didn't fit well. C++ kept not only the good, but the bad and ugly as well.
This digression doesn't really answer the question of the OP, whether C++ is worth learning. I don't share your opinion, but even if I did, the answer would be a strong yes. A much larger quantity of important problems are being solved today with C++ than, say, Go. For employability, it's obviously worth learning (unless you're just doing web stuff). Even if you believe it's broken, it's worth learning to understand why it may be broken and to about those "mistakes" in the future.
OK, fine, C++ is worth learning to learn what not to do, BUT, only after you've learned every other language out there. It's a waste of time to learn it before other languages because you won't have the background necessary to really appreciate how bad the language is otherwise. You might actually think it's a good language and never bother learning all the other better languages out there. Also, anything that reduces the supply of C++ programmers available for businesses to hire is probably a good thing. Fewer C++ programmers means fewer C++ programs and fewer C++ libraries, so hopefully they'll finally start writing frameworks in something other than C++.
Dijkstra's critique of PL/I from "The Humble Programmer" could be carried over essentially unchanged to C++:
"Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control. And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new “features”, little supposing that the main source of his problems could very well be that it contained already far too many “features”. The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more... When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease."
Well all of those solve concurrency and scale problems in the VM and build a language on the top. C++ is just a language in which you are free to build those abstractions into in any form you choose. Batteries aren't included but are easy to construct. If that wasn't possible, then our SQL server installation (all c++) wouldn't quite happily run a single process on each of our 48-core nodes with 128Gb of RAM, nor would it cluster and replicate amongst all 8 of them and deliver 10,000 queries a second whilst yawning.
Cats can be skinned in a multitude of different ways. No specific knife is required but some experienced knife-wielders are more important.
Rob Pike is pretty cool but has blinkers on as he's a captive research executive rather than someone with dirty hands on the ground in some enterprise outfit.
Well all of those solve concurrency and scale problems in the VM and build a language on the top.
I think you're quite mistaken here. These languages solve concurrency at the language semantics level, and then, some of them implement the semantics in a VM, but the VM (in case of Erlang, no Go implementation in use has one) is a tangential issue. To say that these language "solve concurrency problem in the VM" simply doesn't make sense. Languages are languages, they are not implementations.
C++ is just a language in which you are free to build those abstractions into in any form you choose.
Well, there's Turing completeness, and then, there's actual usability. Consider transactional extensions, for example. Haskell gives you a type system for that. In Lisp, you could achieve the same using a code-walking macro library. C++ gives you...what, pattern-matching based template metaprogramming? Ugh! The "language" for that, while Turing-complete, isn't even identical to the one used for run-time code. I've seen a factorial written that way. I don't want to imagine how more complex code like that must look like in C++. Even D is better at that!
If that wasn't possible, then our SQL server installation (all c++) wouldn't quite happily run a single process on each of our 48-core nodes with 128Gb of RAM, nor would it cluster and replicate amongst all 8 of them and deliver 10,000 queries a second whilst yawning.
I didn't say it's impossible in C++. It's just that it's masochistic, that's all. You could easily argue along the same lines that COBOL is a well-designed language because millions of applications have been written in it that power the reliable day-to-day operation of banks you've invested your money into. Yes, they have been written, but at what human cost?
Rob Pike is pretty cool but has blinkers on as he's a captive research executive rather than someone with dirty hands on the ground in some enterprise outfit.
"Captive research executive?" What does that even mean? He certainly has more than enough of his share of dirty hand, while continuing doing so even today, and I won't even comment on that "enterprise outfit" nonsense.
Well erlang and go do have a virtual machine concept because they are basically flip off great big coroutine schedulers at the end of the day (or are they OS's?). Go and erlang give nifty coroutine initialisation and communication stuff - that is all with language constructs on top. c++ has none so you're free to choose depending on what you need to do. It's a good general purpose language.
Usability is perfectly fine when you consider C++11 and boost for example. They both can the useful abstractions.
Transactional code is pretty easy. You can do it fine with closures you know, elegantly without resorting to metaprogramming monstrosities. Metaprogramming is a PITA in large systems from a maintenance perspective.
Its not as masochistic as finding erlang developers. Nor is it all that masochistic actually if you consider the good old CSP paper and apply that to your code.
The "enterprise outfit" nonsense is us large businesses who have a vacuum of quality staff because people would rather work at google (for a lesser salary I'll add) where they can take on menial duties and be kept away from the competition. We build really big, complicated systems like you've never seen with "inferior" tools, low quality staff, very little CPU time and not a mention of erlang or Go. In fact some of our shit is handling 1000 requests a second on VB6+DCOM.
That's not universally true. Some people can't give up C++'s sugar once they've become addicted to it, but you also have people like Martin Sustrik abandoning C++ for C. (I would say, moreso, people recognizing where C++ can provide a real benefit and those places where it's unnecessary.)
I wouldn't say that you ever "learn" c++, it's more a lifelong activity of understanding the intricate details various disjoint concepts and how they interact.
I would say that it's a good thing to at least keep an eye on and have some understanding of. If not for anything useful then you can at least experiment with http://libcinder.org/. I do also find reading the c++ standards committee articles a worthwhile activity just to further my understanding of how things like lambda expressions can be implemented and their impact on other concepts.
What languages do you already know? What problem are you trying to solve?
I would learn C++ if you need to know it to get your job done.
Like others have said, C++ is a complex language. Some people don't like it as a "language", some people like all the features it has. But at the end of the day, it is complex to learn and understand.
Also you have to think about a lot when programming in C++. You have to think about objects in terms of their life cycle. Compared to a garbage collected language, this accounts for mental overhead that could be applied elsewhere.
A couple of other negatives about C++:
1) Its harder to interface than C.
2) It has many different flavors that vary depending on what platform you are on.
3) Up until C++11 it didn't have built-in regex.
A couple of positive things about C++ and learning C++:
1) The STL is great, and has patterns that you can apply to other languages.
2) Generic programming to write re-usable code in C++ can be quite fun, and you can learn how the compiler can help you during compile time (+).
3) Learning OOP in C++ can be an artform, and can be fun. There is a lot of bad C++ out there, but there is some very elegant C++ out there as well.
4) You will learn that C++ is not C. You will also learn to chuckle at anyone that writes "C/C++". (Hint, if they write this, then they do not know C++)
(+) Note on this point: Some people from the more dynamic languages might poo poo this as not needed, and that in their favorite language you don't need to define types. This is a mixed bag, on one side, that is true and can let good programmers work faster. However, they either have to not test, or perform all tests at run-time. A compiler and linker can tell you much faster if you have done something stupid like call a method that doesn't exist. In a dynamic language, you have to write tests and hope you happened to test that branch of code where you made the mistake.
118 comments
[ 6.4 ms ] story [ 149 ms ] threadAnd afaik most game engines are written in C++ because of performance and memory management.
So why the heck are you asking the question ?
you already know the answer.
The game industry uses C++ because most of it is consistently about ten years behind the rest of the industry (remember how long it took them to switch from asm to C? and then from C to C++) -- the charitable viewpoint for this is that the industry is conservative; this is also a consequence of the toolset in the embedded world.
Any natively-compiled language with a good compiler will produce pretty fast code without too much work, but to get really fast code in any language, you really need to know what the compiler is doing and be able to tweak it from the language; writing really fast code in C++ requires about as much work and as much thought (but less knowledge of your target compiler and runtime) as writing really fast code in Common Lisp or Scheme.
It's important to note that it's actually easier to write slow code in C++ than in C if you're not careful; C++'s powerful abstractions cut both ways. Unless you explicitly forbid a number features, C++ takes away your ability to look at an isolated block of code and get an approximate "in-head" assembly of it.
All that said, if you want to work in the game industry, you need to learn C++, you have no choice. But at the same time, you could be experimenting with building games in newer languages like D, Rust, and maybe more exotic choices like SML using MLton or Gambit Scheme (maybe using Stalin for a final pass).
I hope this is helpful.
Should you learn it? There's still a ton of software written in it and it has one of the best compiler ecosystems; for many applications it's one of the only practical options for a production system. Every programmer should know enough C++ to understand templates, RAII, operator overloading, things like that, if only to compare with approaches in other languages.
Should you build new systems in it? I would avoid it if possible, but once you learn the language, hey, maybe you'll love it. And if so, there's no shortage of C++ programmers to work with you.
"...abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with no overhead compared to hand-crafted code."
This is superficially similar to the Lisp community's "sufficiently advanced compiler," but in C++ it really means that high-level features are thoroughly undermined by low-level concerns (as opposed to just being slow until better compilers come along). Other languages seem to get high-level abstractions right, in the sense of exchanging a constant-factor loss in performance for a large gain in programmer productivity.
Also, why limit ourselves to "mainstream" languages? Once upon a time C++ was not mainstream. Why should we shy away from Lisp, OCaml, or Haskell just because they are not popular? In every discussion about C++ and its technical ups and downs, someone points to its popularity, as if that were some kind of justification. The history of computers is overrun with examples of popular-but-inferior technology.
(edit: C++'s main deficiency against C# and Python is its lack of a reflection system. Against Haskell, C++ is well known for being similar, but templates in C++ are more flexible and less constraining than Haskell's type system features -- for example if you want to overload + you don't have to buy into the entire Num typeclass.)
Really though, my big issue with C++ is that the high-level features are bogged down by low-level details -- if I wanted to deal with low-level details I would not be using high-level features in the first place. Why should I have to manually determine how to capture variables in a lexical closure? Why should I have to manually declare "virtual" inheritance to deal with the multiple inheritance diamond? Why are destructors not virtual by default? Why are string literals still pointers to character arrays, why are arrays still not bounds-checked, why are integers still fixed-width (and why are integer overflows not reported as errors?)? Yes, these things all make sense sometimes but in most cases they are the opposite of what you want -- you should have to write more code to get this behavior than to avoid it.
I disagree here. First, the nature of the language is no excuse -- I am criticizing the nature of the language to begin with. Second, in this case, there is a sensible default: always capture by value. If you need or want to capture by reference, create a reference and capture that -- which is already what people have to do when they return a closure and use smart pointers to maintain the lexical environment.
"The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language)."
Except C++ does not maintain compatibility with C, and "performance" is not an excuse either. If performance is a concern, create a keyword to disable default behavior; e.g. if you want to not have a particular destructor be virtual, then there should be a keyword for that. Even compatibility with C is not an excuse -- already the extern "C" syntax is used to disable the name mangler, so why not go all the way and have it also disable things like array bounds checking and creating string objects for string literals?
Basically, C++ is a language that makes unsafe code easier to write than safe code; this is the opposite of what a high-level language should do.
All the things you want would incur a performance penalty were they the default.
Edit: Also, I don't know much about Lisp, despite being a bit of a Scheme weenie in the past. When I try to think about whether I'd like to implement some hypothetical project in Lisp or C++, the most important difference between them seems to be garbage collection. It's more realistic to ask whether I'd rather use Lisp vs. Java, or Lisp vs. Scala, or Lisp vs. C# or Python or Ruby, than C++, because garbage collection is a big issue that makes it difficult to compare them by some notion of how it would feel to use the languages.
I have a hard time evaluating whether macros are really that useful. Whenever I see people give examples of using macros, usually it's just superfluous, something that could be done a bit more verbosely without macros in a language like Python or Ruby, or done a bit superiorly in something like Haskell. And if it were a situation where macros were very useful, all I can think then is (now let's pull some anti-macro tropes out of the hat!) how debuggable is this? And would it really be that hard to solve the same problem in one of the other languages?
Oh yeah, let's put Chromium, Firefox, and all of KDE on that list too.
As a person who is proficient in both C and C++, I find this constant war ridiculous. Neither languages are obsolete ok? Which one is best for you depends on the circumstances. Stop speaking in absolutes.
https://en.wikipedia.org/wiki/Constraint_programming
"I am already familiar with C, as well as Python, Go, Java and a few other scripting languages."
In terms of relevance in the real world, those languages cover pretty much all bases. The only reason I can see for learning more languages would be to learn entirely new ways to think about programming i.e. different paradigms. Functional programming is fine as far as that goes, but constraint programming is even more radically different (it is not likely to be viewed as simply a "style" of programming that can be used in C or Python), so I mentioned it.
Now only you will truly know if C++ is suitable for the tasks you do but unless you work at a university then chances are C++ will be good to great for whatever you need.
As for C it is a great language but it is pretty much only for either old stuff or system level stuff. In the real world I see people pick C++ over C if possible.
If you're doing any embedded programming you're going to be using C. C++ is pretty much exclusively used in the gaming industry, and there mostly because of historical reasons more than anything else (all the popular frameworks are written in C++).
I'm curious how you've come to that conclusion? C++ is used in most of the major web browsers, most of the major database engines, most of the major office program suites, it's widely used at Adobe, Microsoft and Google... C++ is in the top 5 of most language popularity rankings (TIOBE, langpop).
Sure, C++ has its issues, but claiming it's only used in one industry is way off base.
As for office suites, there's three of them out there, MS, which is C#, Apples which is ObjectiveC, and LibreOffice which so far as I know is Java.
I wouldn't be entirely surprised if a lot of the DB engines are done in C++, but I also would expect quite a few of them to be done in C as well. DB engine is a rather specialized area that demands the best performance you can possibly achieve, so something low level like C or C++ is to be expected. In order to achieve top performance you need to sacrifice ease of use so a really basic language like C or C++ is expected.
Interestingly enough looking at the source code for Firefox there is indeed some C++, but there's actually a lot more JavaScript in the Firefox source tree than there is C++.
On a closed-source project, it's hard to get the details. But the open source projects, however, we can get a very clear picture.
The point I'm trying to make is that C++ is widely used, and definitely not used just for gaming.> Most new development isn't done in C++
Whether or not C++ is the right choice for new development is a different question. Github posted their top 20 languages for new repositories in 2013 [5]. C++ is #6 and has more new projects than C, Objective-C and C#. Even if it's fading in popularity, that's still a lot of new projects in C++.
[1] http://www.ohloh.net/p/openoffice/analyses/latest/languages_...
[2] http://www.ohloh.net/p/libreoffice/analyses/latest/languages...
[3] https://www.ohloh.net/p/firefox/analyses/latest/languages_su...
[4] http://www.ohloh.net/p/mysql/analyses/latest/languages_summa...
[5] http://adambard.com/blog/top-github-languages-for-2013-so-fa...
Source: I work at Google and use all the languages in use at the company (including both C++ and Go) on a daily basis.
The answer to that question, IMHO, is yes which is what the OP wanted to know. Had they asked what languages they should learn I would put other languages above C++ but that wasn't their question :)
Maybe so, but the programmers I know who have switched from C++ to Haskell/OCaml/F# never seem to regret it. They are getting more done in less time, and spending a greater fraction of their time writing good software than tracking down annoying low-level bugs. The small trade-off in performance does not seem to be an issue, and in the few places where it is, some C or assembly code invoked via an FFI solves the problem.
"C++ is still one of the most flexible languages for application development"
Only if you are not counting the overhead of actually getting a complex C++ application to work reliably. Even the new abstractions in C++11 and C++14 seem to force programmers to deal with low-level issues than in almost every case are a distraction from the high-level problem being solved.
All languages make tradeoffs. You need to understand your domain and the tradeoffs associated with them.
It's likely that your idea of what is 'inherent' to C++ is just wrong. First of all, C++ is almost a superset of common C so, yes, it can can really replace C entirely and completely. Whatever grievances you have with the language don't change the reality that even embedded code benefits from, and has been gaining ground in, C++ for quite some time.
In any case, I'm not arguing C++ is inherently 'better' than C. I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical.
We do still have a need for a low-level language; C is not the greatest language but it gets the job done. There is also quite a bit of C code out there, proof-of-concept code, reference implementations, etc., and so not knowing C means being cut off from all of that. C++ is not as commonly used for such things, or if it is then only a minimum subset of it is used, and it has no advantage over C as a low-level language. The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction; this has not changed with C++11 and it does not look like it will change with C++14.
So really, the only good reason to be learning C++ in this day and age is if you need to extend or maintain some part of the massive body of already-written C++ code. In other words, if you need to deal with legacy code.
> We do still have a need for a low-level language
C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?
> There is also quite a bit of C code out there... not knowing C means being cut off from all of that.
I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy.
> The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction
Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?
Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible".
On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.
I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?
I recently (about 2 years ago) started writing, on and off, a new IDE for Clean in C++ with Qt. No complaints. I somehow like it better than C# with all its drag and drop capabilites (yes Qt has that also). However, somehow I like Qts way of doing it better...Don't know what I wanted to say with all this, I just prefer C++ and would choose it for applications. Unless demanded otherwise.
What I said was that C++ has no advantage over C as a low-level language. When you are writing low-level code you usually do not appreciate implicit function calls, extra data being allocated that you did not explicitly declare, name mangling, etc. Low-level C++ code is basically C with a slightly modified set of annoyances balanced by a small set of conveniences.
"Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?"
It is not about being slick and elegant, it is about being productive. The majority of applications are high-level, and the programmers who write those applications get more done when they use high-level languages.
Sure, sometimes an application needs to do a few low-level things. For some high-level languages that means using an FFI (e.g. JNI for Java). We could do better if we wanted; CMUCL and SBCL are Lisp implementations that do a fantastic job of separating high-level and low-level constructs, so that you would never know the low-level features existed if all you wrote was high-level code. With C++, you get something very different: high-level code is tangled up with low-level constructs, issues, and reasoning.
"I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible"."
Actually, I switched from C++ to Lisp after having programmed in C++ for more than a decade. This is not a decision I have any serious regrets about. With Lisp I am writing high-level code more easily, and what I am seeing is (a) better performance, (b) the ability to do more ambitious things, and (c) less time spent debugging. Sure, I have bugs in my Lisp code, but those are exclusively high-level bugs -- bugs in logic, bugs that I can fix without having to spend hours tracing pointers. In Lisp, I can report errors anywhere and not have to worry that my program will abort; in C++, sometimes errors just have to go unreported.
It is not that I had one bad experience with C++. I TA'd a data structures course that was taught in C++, and it was a nightmare that left the students with a poor understanding of basic data structures. I have spent countless hours debugging C++ code -- code I wrote, code others wrote, code written by gurus, code that is supposed to solve high-level problems, etc. My group almost missed an important deadline because of the time we had to spend getting C++ code to work. I have worked with people who refuse to even use C++ exceptions because of the all the problems they cause.
Really, I do not mean to rave about Lisp. It is a great language, but there are plenty of other great languages. I liked programming in F#, though I am not an expert in the language. I have seen people switch from C++ to Haskell without ever regretting their decision (including a number of people who said they would prototype their code in Haskell, then rewrite it in C++ when they needed better performance; the rewrites never happened).
"On another note, C++ is at least improving"
I found C++11 to be a disappointment, and C++14 is looking to be more of the same. C++11 contains lots of fixes to problems that are particular to C++, and those fixes introduce as many problems as they solve.
For example, AFAIK you cannot have a naked struct in C++. A struct is a class, and therefore can have methods, thus can have constructor and destructor.
Also, exceptions are a big part of C++ that I don't think you can remove?
If you want simple, obvious separation of data and logic, and you don't want exceptions or name mangling, then C is probably a better choice for that domain.
I like C++, but it is not C and is unlikely that one will ever replace the other in all the domains.
OTOH, if you want to write OO and you like C++, then it is not a bad choice.
I think both are being used to write new systems, so neither is legacy :-)
The "class" keyword and the "struct" keyword differ only in default member visibility. You're free to use the struct keyword. Yes, such structs can have member functions, but they change little except to act as a convenience. A "naked struct" in C++ is called a POD ("Plain Old Data") type, and there are a few rules to ensure your structure meets that definition. The standard library has a type trait to test a class/struct to see if it meets that definition (called std::is_pod).
> For example, constructors, destructors, virtual functions, namespaces.
None of these actually interfere with any use cases or domain that I can think of. Constructors and destructors are insanely valuable features, even if you use nothing else. Functions are not virtual by default and impose no overhead unless used.
> exceptions are a big part of C++ that I don't think you can remove?
You can turn exceptions off at the compiler level. -fno-exceptions in GCC and Clang. RTTI can also be disabled. Disabling both in embedded cases is perfectly reasonable.
> name mangling
extern "C" {} blocks kill name mangling and allow you to export a C API and ABI compatible function.
The answer is "it depends" (of course!). If you plan to hack into some kernel source code, device drivers, legacy software, or high performance softwares, probably it's worthy.
My advice is: once you learned one language for each type (functional, procedural, object oriented) and a scripting language (python, perl, ruby, ...), then get a project and learn while hacking.
Exactly. Still yeah, I agree with you (and Linus Torvalds) on the fact C should be used.
Calling the language you write OS X drivers in C++ is also a stretch: https://developer.apple.com/library/mac/documentation/portin...
C++ is one of the few (maybe the only) languages that gives you enough high-level features to be productive, but doesn't do so at the expensive of ruthless runtime efficiency. If you need to squeeze every ounce of juice out of a machine, but still require the ability to create good abstractions, C++ is for you.
However, for a quick & dirty answer: no, go with C (much more universal).
On another note, if you wonder if you should do, seems like you don't have a reason to... Why are you doing it?
With this said, that's just me and the way the world has worked for me. There are tons of applications were C++ is the right answer and C could never fill the bill. If you just want to learn native and low level programming, learn C instead. Its simpler, easier to learn and has more use cases(Linux kernel, some OS-less micro-controllers)
So to answer your question, "ehhh... sure. maybe?"
You might consider learning C{,++} if:
If you need to interface with hardware at a very low level, such as when you are programming a microcontroller or writing a device driver.
You have a reasonably small application and you need the best performance possible. Don't use them because "C++ is fast". C++ is fairly fast by default, but so are many other languages where it's harder to shoot your foot off. Use C or C++ because of the greater scope for optimization in memory layout and other sorts of painstaking optimizations.
Learn it because you want to create a library that can be used by many other different languages. Pretty much any language has some method of calling a C function, it's pretty simple. Making calls between languages that have their own garbage collectors is more complicated.
Learn it to teach yourself about how your computer works. you could also use assembly language here, but C works well enough. Getting a sense for how other languages work under the covers can help you understand performance trade offs in other languages better.
Only someone who never used templates or did template metaprogramming would state such a thing ;). C and Java -> C++ is not just a matter of syntax.
You don't learn C++, you live C++. So for your case, no.
give some context.
"Is C++ still worth learning for this or that kind of job or field?" is the question you should have asked.
Now i would say most programming languages are still built on either C or C++, and a lot of them allow C or C++ extensions,even hipster's nodejs. You cant be an expert on these solutions/languages without knowing the lower level.
1. You do any desktop programming. You will meet c++ along the line somewhere for certain, be it some win32 abstraction, Qt, Wx etc. I'm ignoring apple here for ref.
2. If you're writing high performance software (scientific computing, gaming, trading etc).
I can't really see many other use cases that can't be solved either via C or a high level language easily.
To be honest I really was indifferent about C++ for years but C++11 seems pretty good so far. I can see it creeping in places where JVM/CLR are being pushed a bit hard and in the systems programming space, but on the basis that some people like myself are still maintaining oooold c++ code, I can't see that being that soon.
That sounds like a red herring. Can C++ be easily compiled for heterogeneous architectures and distributed systems? Does it support massive concurrency in the Erlang/Go style? Is it easily and efficiently vectorizable the way that APL was once? Somehow I've always felt that C++ can do "anything" at the cost of "being equally bad at everything". Regarding C++11, I really like Rob Pike's comment on how the creators of C++ seem to think that the problem of pre-C++11-C++ was that "it apparently didn't have enough features".
First of all, it's not my line, it's Rob Pike's line. Second, upon seeing how the C++ people intend to fix deficiencies of C++ by throwing even more features at it, it's very difficult to see it in any other way. Third, the only "anti-intellectualism" I see here is named C++: It's actually symptomatic of certain organizations that instead of trying to see the big picture and really fix things in a systematic way, they "anti-intellectually" hack and tweak and tinker and micro-optimize. For example, IBM has been doing that in the 1960s with their HW architectures before they got their shit mostly together, which is why the ACS project failed, only for it to be rediscovered forty years later, with modern CPUs finally (!) utilizing these ancient but very well working techniques, such as superscalar out-of-order design that will celebrate its fiftieth birthday in a few years. Now, the same breed of people who ditched ACS in the 1960s are apparently in charge of design of mainstream languages. I wonder if we'll survive the next decades in good mental health before enough people realize the same thing again, ditch that crap and start all over again.
"Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control. And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new “features”, little supposing that the main source of his problems could very well be that it contained already far too many “features”. The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more... When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease."
Cats can be skinned in a multitude of different ways. No specific knife is required but some experienced knife-wielders are more important.
Rob Pike is pretty cool but has blinkers on as he's a captive research executive rather than someone with dirty hands on the ground in some enterprise outfit.
I think you're quite mistaken here. These languages solve concurrency at the language semantics level, and then, some of them implement the semantics in a VM, but the VM (in case of Erlang, no Go implementation in use has one) is a tangential issue. To say that these language "solve concurrency problem in the VM" simply doesn't make sense. Languages are languages, they are not implementations.
C++ is just a language in which you are free to build those abstractions into in any form you choose.
Well, there's Turing completeness, and then, there's actual usability. Consider transactional extensions, for example. Haskell gives you a type system for that. In Lisp, you could achieve the same using a code-walking macro library. C++ gives you...what, pattern-matching based template metaprogramming? Ugh! The "language" for that, while Turing-complete, isn't even identical to the one used for run-time code. I've seen a factorial written that way. I don't want to imagine how more complex code like that must look like in C++. Even D is better at that!
If that wasn't possible, then our SQL server installation (all c++) wouldn't quite happily run a single process on each of our 48-core nodes with 128Gb of RAM, nor would it cluster and replicate amongst all 8 of them and deliver 10,000 queries a second whilst yawning.
I didn't say it's impossible in C++. It's just that it's masochistic, that's all. You could easily argue along the same lines that COBOL is a well-designed language because millions of applications have been written in it that power the reliable day-to-day operation of banks you've invested your money into. Yes, they have been written, but at what human cost?
Rob Pike is pretty cool but has blinkers on as he's a captive research executive rather than someone with dirty hands on the ground in some enterprise outfit.
"Captive research executive?" What does that even mean? He certainly has more than enough of his share of dirty hand, while continuing doing so even today, and I won't even comment on that "enterprise outfit" nonsense.
Usability is perfectly fine when you consider C++11 and boost for example. They both can the useful abstractions.
Transactional code is pretty easy. You can do it fine with closures you know, elegantly without resorting to metaprogramming monstrosities. Metaprogramming is a PITA in large systems from a maintenance perspective.
Its not as masochistic as finding erlang developers. Nor is it all that masochistic actually if you consider the good old CSP paper and apply that to your code.
The "enterprise outfit" nonsense is us large businesses who have a vacuum of quality staff because people would rather work at google (for a lesser salary I'll add) where they can take on menial duties and be kept away from the competition. We build really big, complicated systems like you've never seen with "inferior" tools, low quality staff, very little CPU time and not a mention of erlang or Go. In fact some of our shit is handling 1000 requests a second on VB6+DCOM.
Go figure...
In general, I'd say no. The niche it fills (high-level features bolted on to a low-level language) is not that useful and it doesn't fill it well.
C, on the other hand, is worth learning.
I would say that it's a good thing to at least keep an eye on and have some understanding of. If not for anything useful then you can at least experiment with http://libcinder.org/. I do also find reading the c++ standards committee articles a worthwhile activity just to further my understanding of how things like lambda expressions can be implemented and their impact on other concepts.
I would learn C++ if you need to know it to get your job done.
Like others have said, C++ is a complex language. Some people don't like it as a "language", some people like all the features it has. But at the end of the day, it is complex to learn and understand.
Also you have to think about a lot when programming in C++. You have to think about objects in terms of their life cycle. Compared to a garbage collected language, this accounts for mental overhead that could be applied elsewhere.
A couple of other negatives about C++:
1) Its harder to interface than C.
2) It has many different flavors that vary depending on what platform you are on.
3) Up until C++11 it didn't have built-in regex.
A couple of positive things about C++ and learning C++:
1) The STL is great, and has patterns that you can apply to other languages.
2) Generic programming to write re-usable code in C++ can be quite fun, and you can learn how the compiler can help you during compile time (+).
3) Learning OOP in C++ can be an artform, and can be fun. There is a lot of bad C++ out there, but there is some very elegant C++ out there as well.
4) You will learn that C++ is not C. You will also learn to chuckle at anyone that writes "C/C++". (Hint, if they write this, then they do not know C++)
(+) Note on this point: Some people from the more dynamic languages might poo poo this as not needed, and that in their favorite language you don't need to define types. This is a mixed bag, on one side, that is true and can let good programmers work faster. However, they either have to not test, or perform all tests at run-time. A compiler and linker can tell you much faster if you have done something stupid like call a method that doesn't exist. In a dynamic language, you have to write tests and hope you happened to test that branch of code where you made the mistake.