As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
A friend of mine decided to learn some lower level language (to increaze his abilities) so he is thinking C. Or maybe C++?!
He does not know either to just learn C or go full way with C++.
He asked me what are they used for and couldn't tell him (its been a while since I last used either C or C++).
So my question, trying to help my friend, is What are they best at, C and C++?.
When you need C++ and when is C enough?
P.S. I am not trying to start a war or argument. I don't want syntax explanations like C does not do templates or does not have classes to better think in OOP etc. I just want to know what are the strongest points of each as applicability, functional solutions
At a very high level, there's nothing you can do in C++ that you couldn't already do in C. The main difference between the two languages is the level of abstraction at which they work.
C is a mid-level systems programming language designed to be a thin, portable layer over the machine's underlying hardware. It's designed to be small, so that the language can easily be ported from one machine to another, but expressive, so that you can build complex systems on top of it. C excels in embedded environments, or areas where resource constraints are so extreme that you need to manually manage all of the details yourself (for example, OS kernels, embedded devices, etc.)
C++ is, in the words of its creator, "a general-purpose programming language with a bias toward systems programming that 1) Is a better C, 2) supports data abstraction, 3) supports object-oriented programming, 4) supports generic programming." It evolved as a programming language with runtime performance comparable to C but with higher-level language features more suitable for structuring large, complex systems. The language is significantly more complex, but is a lot more expressive and maps more naturally to the way that you think about programming problems. While you can get the performance of raw C, often programs in C++ will make small sacrifices in runtime efficiency for simplicity of programming.
I can't think of a single application where C would be strictly better than C++ or vice-versa. C++ programs are on the Mars rovers, internet routers, video games, etc. C programs are what power Linux and Windows. There really isn't a clear winner of one over the other. That said, I'm personally more preferential to C++. I think that it's much easier to encode a design in C++, since the language is richer and you can be more precise about what you mean.
Either language would be a great starting point. Learn C if you want to get up and coding quickly. Learn C++ if you want to invest a little more time, but want to build larger systems.
C:
Support for more weird built-in custom microcontrollers.
C++:
OOP, lots and lots of prebuilt libraries (boost).
Go for C++!
If the goal is just to learn, pick C. It's a very small language, and you can do a lot with it. There are many open-source projects that you can look at for examples of good code.
It's great for making things that need to be deployed as machine-code or language-neutral libraries.
Once you have used C a lot, you might understand why C++ was invented and how you might use it.
Even if you start out with the goal of learning C++, you need to learn a lot of C to accomplish your C++ learning.
If the goal is to learn a lower level language, C++ is considered higher level than C. Might as well go low, since that's part of the goal. If you really want to go low, learn assembly (but not Intel assembly, that's just inflicting pain without benefit). RISC or MIPS styled assemblies are a good choice, but the non-Intel slant probably reduces the hardware your friend has available.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am relatively new to programming and want to be able to make native C++ programs for Linux and Windows.
I am just wondering as a beginner should I first of all learn low level languages such as C and assembly in vim or should I just straight out start in an IDE with C++?
If you want to learn C++, learn C++. Learning C or assembly language first is not only a waste of time, but usually teaches relatively poor habits that you need to work at un-learning before you use C++ well.
That's not to say that knowing C or assembly language makes it impossible to use C++ well -- but each requires decidedly different mind-sets, so it creates extra work.
If your ultimate goal is to learn C++, it is not a prerequisite that you learn C first. You can, but you don't have to.
The bottom line is, do what you feel most comfortable doing.
C++ is not (really) a high-level programming language. You're still manually managing your memory and getting undefined environment-specific behavior whenever you make a minor programming mistake. Besides that, C++ is a very unfriendly language for new programmers because it is both overly complex and (in my opinion) horribly designed.
I recommend starting with an actual high-level language like Java, Python or C# in combination with a fancy IDE. Starting with C is also an option if you want to concentrate more on low-level aspects rather than general programming techniques and paradigms.
Also you don't have to learn vim if you want to start programming, a simple editor such as gedit or Notepad++ will also work perfectly fine. An IDE specifically designed for your language is probably the most comfortable, though.
EDIT: As Jerry Coffin has correctly pointed out, this advice isn't really helpful if your goal is to program C++ applications. Although I'd still recommend starting with an easier (high-level) language to obtain general programming skills before you start with C++. If C++ isn't absolutely neccessary for the thing you want to achieve, it also isn't a bad idea to reconsider whether you actually want to use that language.
If you want to learn C++, start with C++. You don't need to learn C first; it would actually be somewhat counterproductive, since you'd have to unlearn some stuff when you moved to C++.
C and C++ are different languages, with different goals and philosophies. A well-written C++ program will not look or behave much like a well-written C program.
Once you get comfortable with high-level C++ features, then you can start delving into the lower level details.
"If I have seen further it is by standing on the shoulders of giants."
-Sir Issac Newton
Do not reinvent the wheel.
start as high and abstracted from the core as you can, and only revisit the core when there is no other way to advance in your road.
Your question seems to me being more about learning programming.
Language choice may be secondary to learning the programing paradigms/concepts.
So if programming is your focus, then you may first learn object oriented programming (OOP) concepts, so that you don't have to "adopt" them in a way people coming from procedural approach often do. Then, if needed, you may dig into procedural way and some C idioms/tricks and low-level approaches.
OOP can be taught in C++ as in Java etc. does not matter on that stage.
Once your mindset is "oriented", then the actual programming will be more about using existing libraries (APIs), which in fact will require more learning than the language itself.
So my advice is to learn OOP concepts first, then review your future language preferences. Have fun!!
Javascript is the first language I learned and I feel lucky that it was. With it I was able to skip past alot of the intricacies and barriers of other languages like static typing, pointers, and compiling. With javascript, you don't even have to install anything, just go here and you can begin trying things out: http://jsfiddle.net/X4PpW/ .
After I had a strong grasp of Javascript, understanding the concept of using pointers and classes in C was easy for me. Another good language to start with would be Python.
Also, what do you intend on making? Not all desktop apps have to be written in C. In fact some new frameworks out there borrow ideas from web applications or even allow embedding HTML from websites into your app.
Games: Unity3d http://unity3d.com/ (Games written in this can be ported to mobile devices or the Web but requires a plugin)
General app with UI : QT http://qt.nokia.com/products/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've read that Fortran is still heavily used for scientific computing. For code already heavily invested in Fortran this makes sense to me.
But is there a reason to use Fortran over other modern languages for a new project? Are there language design decisions in Fortran that makes it much more suitable for scientific computing compared to say the more popular languages (C++, Java, Python, Ruby, etc.)? For example, are there specific language features of Fortran that maybe allow numeric optimization in compilers to a much higher degree compared to other languages I mentioned?
Fortran is, for better or worse, the only major language out there specifically designed for scientific numerical computing. It's array handling is nice, with succinct array operations on both whole arrays and on slices, comparable with matlab or numpy but super fast. The language is carefully designed to make it very difficult to accidentally write slow code -- pointers are restricted in such a way that it's immediately obvious if there might be aliasing, as the standard example -- and so the optimizer can go to town on your code. Current incarnations have things like coarray fortran, and do concurrent and forall built into the language, allowing distributed memory and shared memory parallelism, and vectorization.
The downsides of Fortran are mainly the flip side of one of the upsides mentioned; Fortran has a huge long history. Upside: tonnes of great libraries. Downsides: tonnes of historical baggage.
If you have to do a lot of number crunching, Fortran remains one of the top choices, which is why many of the most sophisticated simulation codes run at supercomputing centres around the world are written in it. But of course it would be a terrible, terrible, language to write a web browser in. To each task its tool.
The main reason for me is the nice array notation, and many other design decisions that make writing and debugging scientific code easier. The fact that it is usually the best choice in terms of performance on the relevant tasks (array operations) does not hurt either :)
Honestly, I would not consider most the languages cited as real competitors for Fortran -- Java and Ruby are far, far behind in terms of both convenience and performance, while C++ is much too complex and tricky a language to recommend to anyone whose main job for the last few years has been anything other than daily programming in C++. Python with numpy could be an option though. I am personally not a huge fan of the language, but I know a number of people who use numpy regularly and seem quite happy with it.
Real competition I see is not from these, but from Matlab, R, and similar languages, that offer similar convenience, combined with many standard libraries. Luckily, it is usually possible to start a project in R or Matlab, and write performance-critical parts in Fortran later.
Few projects are completely new projects. I'm not sure it's specific to scientific computing, but at least in this field, you tend to build your applications based on existing (scientific) models, perhaps produced by other groups/people. You will always have to deal with some amount of legacy code, whether you want it or not.
Fortran is what a lot of scientists have been taught with and what a lot of the libraries they need are implemented in. A number of them might not be computer scientists or IT people, more computational scientists. Their primary goal is rarely computing, it's their science first.
While a large number of programmers would have a tendency to learn a new programming language or framework whenever they get a chance (including during their spare time), most scientists would use that time exploring new ideas regarding their science.
A domain expert who's trained in Fortran (or any language) and surrounded by people who are in a similar situation will have no incentive to move away from it.
It's not just that now other languages can be as good as Fortran in terms of performance, they need to be much better: there needs to be a good reason to move away from what you have and know.
It's also a "vicious" circle to a degree. I've always found comparisons between Java and Fortran a bit difficult, simply because a number of Java scientific applications are not programmed in a Java way. Some of the Java Grande benchmark applications look clearly like Fortran programs turned into C programs, copied/pasted/tweaked into Java programs (in a method, passing the length of the array as an extra parameter next to the array itself gives a clue, if I remember well). Because of this, Java (for example) hasn't got a great reputation in the scientific community, even though its performance is getting better. A consequence of that is that there is little overlap between HPC experts and Java experts, for example. Even from the hardware vendors or libraries implementors, little demand from users leads to little support offered, which in turns deters users who would potentially be interested in moving to other languages.
Note that this doesn't preclude the same (or other) scientists from using other languages for other purposes (e.g. workflow management, data management, quicker modeling with Matlab, Numpy, ...).
As I understand it, there are libraries that are some of the most efficient implementations of their algorithms available, which makes Fortran popular for this kind of work in spite of the language's limitations.
One reason is in how the arrays were constructed. They are column major, unlike most other languages. This provides faster computation for their calculations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For each new low-level program or library I write on POSIX systems, I always have to start out with the initial decision: do I write it in vanilla C, or do I go with C++? I like to think that each time I'm making a relatively informed decision, but I wonder if there's something I'm missing.
This isn't a which is better question, but rather, what aspects of each are better? Presumably, each has compelling strengths. In which cases should I chose the one instead of the other?
For example, below are some of the points I consider. What else am I missing?
Favoring C
Compatibility: Virtually every language and framework has some mechanism for interfacing with code written in C.
Simplicity: Debugging template code makes you age faster
Popularity: Think of all your favorite applications, servers, interpreters, and other tools. Chances are most of them are written in C, even though C++ was available when they started. All the cool kids use C.
Favoring C++
The STL: You certainly could implement your own RB-tree, quicksort algorithm, or double-linked list. But it probably won't be as good.
Templates: Sure, it's a pre-processor function masquerading as a language feature, but it sure is convenient.
Classes: C++ isn't exactly smalltalk, but at least it's not fancy assembly language either.
Compatibility: You can still use C in a C++ project.
I think you're making it more complicated than it really is. Which language are you better at in expressing your idea? If neither, and if you're a beginner at both, use C; otherwise if you're good at both pick what you feel like. Otherwise it doesn't matter nearly as much as just starting.
Alice: Would you tell me, please, which way I ought to go from here?
The Cat: That depends a good deal on where you want to get to
Alice: I don't much care where.
The Cat: Then it doesn't much matter which way you go.
Alice: so long as I get somewhere.
The Cat: Oh, you're sure to do that, if only you walk long enough.
C++ simply has many more features than C. That makes it a more complex language. But the benefit of using these features is that you will have to write (and maintian) less code.
You're not required to use templates, stl, exceptions, function overloads, or whatever C++ feature. But if your problem needs just one of these features, your program will be more readable if you do it in C++, rather than emulating the missing functionality in C.
You forgot to mention that in C++ there are destructors that are called automatically, so when used correctly (RAII) you don't need to worry about resource deallocation. Another good feature are exceptions that could make the error handling easier and more maintainable.
For myself, there is only two reasons to use C. First is if you need the code to be extremely portable (going to be used as a library in different languages and/or operating systems), and second if you need raw speed, which usually isn't a big deal as C++ typically performs only slightly slower than c (not including OO features).
I really enjoy the OO features of C++, which if used properly can make life a lot easier when developing applications.
It sounds like you favor C over C++. I do too. However, ease of use is the most important factor in programming. C++ has better string support and more libraries, so for non-trivial projects, such as database access and stuff like that, go with C++. If you are aiming to be cross platform and maybe want to work on a lower level, use C. Besides, they're both the same anyway.
C++ is better in almost every way: safer, more efficient, works better in large projects... The only exception is that you can't use it when you interface with other languages. But in that case you still use C++ and add a small C layer for the interfacing part.
C has some advantages above C++ in the early phase of a project, it's simpler, easier and requires less design decisions. However, as the project grows so do the advantages of C++ and Object Oriented Code, which are essentially: Encapsulation, Abstraction and Information Hiding. The drawback is usually slightly slower code unless you break encapsulation.
Yes, it's possible to write like C++ in C, too, but it is far more complex and a hell to maintain.
When I have a choice, I go with a subset of C++.
compatibility - not a problem, you can use extern "C" for linking with C libraries
simplicity - avoid templates, overloading operators, and other C++ feature that obfuscate code
You still get the advantages of classes and RAII.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
All,
There are so many programming languages/Operating systems/device drivers i.e. softwares that are built using C and C++. I was wondering if C and C++ were the only 2 low level programming languages that all companies ever had to build their own product(s)? If there are, why do C and C++ get so much preference over other options?
There are many "medium-level" languages suitable for OS development, but C and to a lesser extent C++ are by far the most popular. There are many reasons for this, including:
The early success of C as the implementation of Unix led to its widespread adoption.
The vast availability of great development tools (compilers, lint, editors, memory leak analysis, profiles, code generators, ad nauseam) makes C even more compelling.
The closeness of C to the "abstract machine" level; unlike, say, Pascal, which has considerably more runtime overhead. This is desirable when writing high performance software. C has sometimes been called a "portable assembler" for its closeness to the hardware.
Forth is sometimes used for developing low level software like device drivers. For example the boot prom for SUN SPARC based servers used to be written in Forth. See http://en.wikipedia.org/wiki/Open_Firmware for details.
There are other low-level languages, but C had the benefit of a 'popularity snowball' effect.
It's about as efficient as any reasonably portable language can be, so it's a good choice for systems programming. Once you build an operating system on it, it makes sense to build tools for the same system with it, so a lot of programmers got exposed to it in the 80s and 90s. Thus it became a lingua franca that all systems programmers were familiar with.
There's relatively little you can do to improve on C without compromising either its efficiency or its portability, so there was no obvious place to compete against it at the low level.
I know some people that do systems programming in D. It is lower level than C#, etc. but had many of the same benefits of modern languages.
Even more than the low level of abstraction, the key feature of C and (C++ with RTTI disabled) that is applicable to system software is that they don't need any runtime library.
See, you can write a compiler in the very same language, but you can't write a runtime in the language that depends on it.
C has a standard library but not a runtime library, so you can implement the standard library in C, and you can also use it to write the runtime libraries for other languages. Ditto for C++ (with RTTI disabled).
No, there are absolute bucketloads of languages that companies use to produce their software. C has a clear advantage over all of them for one particular area, that of very low-level stuff, since it imposes very little between the code and the hardware.
Most other languages (including C++ to some extent, unless you restrict yourself to the C side of it) tend to carry a lot of unnecessary baggage which, while an absolute godsend for applications programming, tend to just get in the way for systems level stuff.
Of course, you could also use assembly code but that's rarely necessary nowadays with the quality of the C compilers.
Ada, Pascal, assembly, Fortran, etc etc. Even when you are limiting the discussion to low-level languages, you still have a lot of choices. There are a lot of companies that don't do much C or C++ work at all (for example, the US military does a considerable amount of work using Ada).
One reason C and C++ are so popular is because so many people know those languages (I realize that's a recursive answer). Companies use C or C++ because it is easy to find a developer who knows the language, and developers learn the language because that is what companies are hiring. It also doesn't hurt that there is a very wide selection of books, compilers, IDEs, debuggers, libraries, etc etc for C and C++, and that C/C++ compilers are available for practically any platform you might encounter. Plus, these languages have been around for quite a while. Legacy C code is more likely to be maintained by a C developer than re-written in another language. Both C and C++ are versatile, powerful languages that will continue to be used for the forseeable future. They are far from being the only option, though.
C has been the lingua-franca since the early days of Unix. There is so much existing C code, so much cultural root, that people just use the language. It's more than that: C is so well designed: in its simplicity, in its speed of learning, speed of compiling, speed of coding, speed of running; in its bible-like tutorial book, in the sheer amount of solid open-source code we still use and hack on today, and the list goes on. It's just a useful language, like no pressure-independent, gravity-independent diamond-sparkled million-dollar pen with finger-prints of angels can replace a pencil.
As for C++, it is not nearly as simple as C. On the contrary: it is arguably more complex than roughly any other language out there, in terms of grammar, dark corners, learning curve, proper modern code and other criteria. One would think this complexity would kill the language, and many in fact have been saying this for decades. Java was born on this premise. But here we are today, roughly thirty years after the language was born, and it's still live and kicking among the 10 most popular tags on StackOverflow. There is a number of people that are passionate about the language, yours-truly among them.
Granted, that doesn't explain why C++ is thriving today as a popular language. I think it's the freedom C++ gives you in supporting so many different programming paradigms. This is how C++ supports programming both as low a level as C, with that same efficiency, and as high a level as other languages, given proper helper libraries. I recommend you read this interview with Bjarne Stroustrup.
C and C++ certainly are not the only alternatives for low-level programming. But they are an option that is very hard to resist. The best option, if I may boldly suggest, if only for their solid, long history that hints they are both here to stay; and for the repertoire of solid code out there that demonstrates the things you can do with these languages. The support the existing software demands promises lots of active boards on the net, lots of hiring companies -- and all in all a live, kicking pair of languages.
How about C#? Many windows applications get built using C#.
How about Perl/Python? Many applications on Windows and Linux get build using those languages.
How about D? Always a nice language to use, but it's sad it does not talk as good as I need with native C++.
Partly because it was one of the first high level languages (after B) that was adopted on a large scale. Languages like Java are owned by companies, which at the drop of a pin could be dropped and then you wouldnt see any updates from oracle. There is also the fact that c and c++ translate to relatively low amounts of assembly code, which makes it much smaller and compact.
There is also, the most important philosophy of C. You dont pay for what you dont need. (i.e in java you have garbage collection, but if you write a program that doesnt need a garbage collector, than you have wasted resources and you pay for it is speed and efficiency.) In C, if you need something, you make it yourself, no lost resources, much more efficient code (depending on the programmer).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,