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".
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.
C++ makes you able to write simple tasks in a complicated ways, thus a great asset to the global hidden mission of software industry which is to write code that will seem brilliant but fail in a devilish way. So go for it.
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” — C.A.R. Hoare, The 1980 ACM Turing Award Lecture
You can also learn more than one langage because they fits domain of excellencies you want to master:
- C low level programming (zmq switched from c++ to C because of error handling)
- high level portable language that can bind on libraries (python to avoid hispter mac users using ruby) ;
- something for concurrency (Go);
- R-project for data treatment;
- vanilla JS because mixing LISP difficulties with braces syntax is insanely cool;
- PHP and Perl to feel with your guts what a wrong language is (hint: it is all about maintainability);
- ASM 68000 because motorola 68000 is the most beautiful mix between a good design and implementation and it will make you truly able to build a consistent mental map of what a computer really is;
- Tk because 25 years it still is the most portable way of doing GUI and has inspired everyone;
- Forth because it is fun to use postscript as a real programming language;
....
I wouldn't learn it unless you're interested in learning new languages already or suspect you'll wind up at a job where it's necessary. If the former, that's a long road and my suggestion there would be to first learn languages that will make you think about programming differently and second learn languages that make programming fun -- C++ is neither, though perhaps for some people they start thinking "I don't want to program anymore", and I guess others who are exposed to C++11's new features for the first time in any language can get excited about them...
If you are going to learn it, learn it in full. Understanding most of http://yosefk.com/c++fqa/index.html ought to be a requirement to put "C++" as a separate item from "C" on your resume; people who put "C/C++" on their resume make me more likely to believe they only know C++ as a kind of super-set of C and they will likely program C++ code in a very Cish style, also they will likely make more mistakes caused by a faulty assumption that C++ does the same thing C does -- like a keyword means the same in C++ as it does in C.
A lot of places have sane requirements and restrictions on what you can do in your C++ programs there. e.g. http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... But to understand the decisions you probably need to learn about the thing being discussed... And then learn why other programmers want the thing to be enforced or restricted so much. A lot of times it's just so even C++ programmers whose C++ knowledge is summarized as "C with classes!" can still be effective programmers.
I wouldn't suggest learning C++11 specifically. Learn C++98, then learn what new features C++11 has on top of that (there aren't that many).
>> "C/C++" on their resume make me more likely to believe they only know C++ as a kind of super-set of C and they will likely program C++ code in a very Cish style
Could "C/C++" on the resume also not mean they see C as a subset of C++, they program C++ code in C++ish style, but also feel comfortable with C? (I understand C is not a true subset anymore, but it seems close enough to allow me to do programming in C every once-in-a-while I need to.)
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.
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.
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.
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.
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?"
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.
Use C++ if you're interested in writing high level abstractions that resonate with the underlying hardware.
Assembly and C map very closely to actual hardware, but don't have a very high abstraction capability.
Haskell, Erlang, Python, LISP, etc. have abstractions up the wazoo, but there's big box labelled "magic" between what you write, and what gets run. That's because it's easy to construct systems which have nice theoretical properties, but are completely incongruent with shipping chips, requiring a black box in the middle that is doing who-knows-what kinds of translations, continuously.
Intel will never ship a CPU which natively executes functional code, for example, because fundamentally computation is an imperative process. You have information (entropy) and you want to turn it into a useful result; that involves moving bits, comparing them, performing simple computations on them, and iterating. That's what chips do, and that's what C++ does too--the fundamentals--but with more abstractive power than C when it is needed.
If you think that being both "in tune" with the hardware and achieving high abstraction in a single language is difficult, you're right--and C++ is difficult to learn and use. There is no free lunch there. But the results speak for themselves. Almost every single piece of software I use on a daily basis is written in C++.
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.
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.
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.
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.
C++ is large and has lots of history and legacy.
There isn't anything you can do in C that can't be done better in C++.
I enjoy C++, and learned as the language right after Visual Basic 6 at around 2008.
You can easily imagine how things "could" be implemented on top of C in C++.
The most difficult thing about C++ is passing over all the negativity hyped by the "other" camps, and then learning from the right people (who will tell you what things have gone wrong and have their own philosophies of using the language). The new standards of the language feel like they're more scripting than erecting object oriented cathedrals. I enjoy reading topcoder submisssions and editorials on their SRM problems. I believe it can give a perspective on how C++ can be used in a terse and narrow domain.
TL;DR: At any place where C makes sense, C++ has a lot to be offered to be ignored. Try to consider the source when checking criticism. Find legitimate examples of C++ from OSS and topcoder SRM submissions.
There are applications today where C++ is still the best choice. For high complexity, performance critical applications (as csmuk mentions - game engines, trading, network software, but also high performance compilers and VMs) no other language has quite the mix of performance, available abstractions, and maturity. The question is then, if these you're into writing these types of applications.
If you're not, then IMO, C++ is not worth learning. In the words of Alan Perlis:
"A language that doesn't affect the way you think about programming, is not worth knowing"
The main contributions of C++ is implementing abstractions well known in other languages - OO, generic programming - in a C-like syntax. C++ is not the best language to learn to understand these concepts - there is too much low level complexity to deal with.
But if you're looking for language with the performance of C and with available high level abstractions, C++ is still the best choice today.
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.
It certainly is for the following reasons.
1) Offers high-level abstractions at high-level performance
2) Does not restrict you to 1 paradigm.
3) Available from multiple vendors on multiple platforms all backed by an ISO standard
4) You used a program written in C++ to write this post
-C++ is very large language and the standards committee works hard to make it larger every day. Every organization makes use of a subset of C++ but likely a different subset. C and Java are much smaller languages.
As John Carmack says "Any abstraction that compiler will accept will eventually make it into a sufficiently large codebase"
-Familiarity with an organization/codebase specific subset of C++ is necessary for a number of significant career paths in software development. Chromium and related technologies, Google's core infrastructure, Java runtime engines, game engine developement etc.
I fundamentally don't think you should try to "Learn C++". If you are interested in career path the has C++ as a prerequisite. Learn the C++ style of a similar OSS project.
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.
[+] [-] csmuk|12 years ago|reply
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.
[+] [-] gngeal|12 years ago|reply
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".
[+] [-] tokenrove|12 years ago|reply
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.
[+] [-] julie1|12 years ago|reply
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” — C.A.R. Hoare, The 1980 ACM Turing Award Lecture
You can also learn more than one langage because they fits domain of excellencies you want to master:
- C low level programming (zmq switched from c++ to C because of error handling) - high level portable language that can bind on libraries (python to avoid hispter mac users using ruby) ; - something for concurrency (Go); - R-project for data treatment; - vanilla JS because mixing LISP difficulties with braces syntax is insanely cool; - PHP and Perl to feel with your guts what a wrong language is (hint: it is all about maintainability); - ASM 68000 because motorola 68000 is the most beautiful mix between a good design and implementation and it will make you truly able to build a consistent mental map of what a computer really is; - Tk because 25 years it still is the most portable way of doing GUI and has inspired everyone; - Forth because it is fun to use postscript as a real programming language; ....
[+] [-] SamReidHughes|12 years ago|reply
[+] [-] okpatil|12 years ago|reply
[+] [-] Jach|12 years ago|reply
If you are going to learn it, learn it in full. Understanding most of http://yosefk.com/c++fqa/index.html ought to be a requirement to put "C++" as a separate item from "C" on your resume; people who put "C/C++" on their resume make me more likely to believe they only know C++ as a kind of super-set of C and they will likely program C++ code in a very Cish style, also they will likely make more mistakes caused by a faulty assumption that C++ does the same thing C does -- like a keyword means the same in C++ as it does in C.
A lot of places have sane requirements and restrictions on what you can do in your C++ programs there. e.g. http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... But to understand the decisions you probably need to learn about the thing being discussed... And then learn why other programmers want the thing to be enforced or restricted so much. A lot of times it's just so even C++ programmers whose C++ knowledge is summarized as "C with classes!" can still be effective programmers.
I wouldn't suggest learning C++11 specifically. Learn C++98, then learn what new features C++11 has on top of that (there aren't that many).
[+] [-] alok-g|12 years ago|reply
Could "C/C++" on the resume also not mean they see C as a subset of C++, they program C++ code in C++ish style, but also feel comfortable with C? (I understand C is not a true subset anymore, but it seems close enough to allow me to do programming in C every once-in-a-while I need to.)
[+] [-] iends|12 years ago|reply
[+] [-] w4rh4wk5|12 years ago|reply
And afaik most game engines are written in C++ because of performance and memory management.
[+] [-] betterunix|12 years ago|reply
[+] [-] FooBarWidget|12 years ago|reply
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.
[+] [-] InTheSwiss|12 years ago|reply
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.
[+] [-] bstamour|12 years ago|reply
[+] [-] nly|12 years ago|reply
[+] [-] w4rh4wk5|12 years ago|reply
[+] [-] stusmall|12 years ago|reply
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?"
[+] [-] jpmec|12 years ago|reply
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.
[+] [-] wrongc0ntinent|12 years ago|reply
[+] [-] codex|12 years ago|reply
Assembly and C map very closely to actual hardware, but don't have a very high abstraction capability.
Haskell, Erlang, Python, LISP, etc. have abstractions up the wazoo, but there's big box labelled "magic" between what you write, and what gets run. That's because it's easy to construct systems which have nice theoretical properties, but are completely incongruent with shipping chips, requiring a black box in the middle that is doing who-knows-what kinds of translations, continuously.
Intel will never ship a CPU which natively executes functional code, for example, because fundamentally computation is an imperative process. You have information (entropy) and you want to turn it into a useful result; that involves moving bits, comparing them, performing simple computations on them, and iterating. That's what chips do, and that's what C++ does too--the fundamentals--but with more abstractive power than C when it is needed.
If you think that being both "in tune" with the hardware and achieving high abstraction in a single language is difficult, you're right--and C++ is difficult to learn and use. There is no free lunch there. But the results speak for themselves. Almost every single piece of software I use on a daily basis is written in C++.
[+] [-] Symmetry|12 years ago|reply
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.
[+] [-] camus2|12 years ago|reply
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.
[+] [-] petercooper|12 years ago|reply
[+] [-] betterunix|12 years ago|reply
"...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.
[+] [-] karlherler|12 years ago|reply
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.
[+] [-] arithma|12 years ago|reply
I enjoy C++, and learned as the language right after Visual Basic 6 at around 2008.
You can easily imagine how things "could" be implemented on top of C in C++.
The most difficult thing about C++ is passing over all the negativity hyped by the "other" camps, and then learning from the right people (who will tell you what things have gone wrong and have their own philosophies of using the language). The new standards of the language feel like they're more scripting than erecting object oriented cathedrals. I enjoy reading topcoder submisssions and editorials on their SRM problems. I believe it can give a perspective on how C++ can be used in a terse and narrow domain.
TL;DR: At any place where C makes sense, C++ has a lot to be offered to be ignored. Try to consider the source when checking criticism. Find legitimate examples of C++ from OSS and topcoder SRM submissions.
[+] [-] leal|12 years ago|reply
If you're not, then IMO, C++ is not worth learning. In the words of Alan Perlis: "A language that doesn't affect the way you think about programming, is not worth knowing" The main contributions of C++ is implementing abstractions well known in other languages - OO, generic programming - in a C-like syntax. C++ is not the best language to learn to understand these concepts - there is too much low level complexity to deal with.
But if you're looking for language with the performance of C and with available high level abstractions, C++ is still the best choice today.
[+] [-] bstamour|12 years ago|reply
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.
[+] [-] RcouF1uZ4gsC|12 years ago|reply
[+] [-] zmanian|12 years ago|reply
-C++ is very large language and the standards committee works hard to make it larger every day. Every organization makes use of a subset of C++ but likely a different subset. C and Java are much smaller languages.
As John Carmack says "Any abstraction that compiler will accept will eventually make it into a sufficiently large codebase"
-Familiarity with an organization/codebase specific subset of C++ is necessary for a number of significant career paths in software development. Chromium and related technologies, Google's core infrastructure, Java runtime engines, game engine developement etc.
I fundamentally don't think you should try to "Learn C++". If you are interested in career path the has C++ as a prerequisite. Learn the C++ style of a similar OSS project.
[+] [-] simgidacav|12 years ago|reply
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.
[+] [-] 4ad|12 years ago|reply