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 the book "Write Portable Code" which details POSH, an open-source "framework" (mostly just a header) to help with portability of C/C++ code between different platforms and hardware.
Since Poshlib hasn't had an update in 5 years now, I was wondering what other similar libraries/frameworks exist out there?
For C code, GLib is a modern cross-platform (non-GUI) library which makes it easy to write applications that run on many different platforms without source code changes. GLib is actively developed in an open manner as part of the GNOME project with lots of open source projects using it.
For C++ I would suggest looking at the Boost libraries.
Dear Shaggy Frog,
While I remain largely incurious about your handle, I must say that this is something of a hairy issue. Here's why. I work with the boost libraries day in and day out. They're fantastic, and make innumerable tasks way easier. But I must emphasis that if you use them, you need to use a profiler. Some of the really nice portions of it tend to be a bit slow, and you should definitely read up on best-practices before using certain parts like, say, transform iterators. Boost, though, is worth mentioning because it does make an effort to supply some pretty powerful pieces of abstraction that are almost foreign in the ++cverse.
However, Boost, and other frameworks like it, are not snakeoil. They rock. People who rock use them. People who rock work on them. For more specialized tasks, I'd need to know more about your problem domain. However, one other tool that's really excellent is SWIG, which will let you bundle up any hunk of portable C code into a library that's... well.... accessible.
As for bloat, a lot of that is going to go away when C++0x moves to the standard, thanks to variadic templates, and a number of similar pieces of cleverness. Honestly, I'm tired of people yelling about The Terrors Of Templates. Perhaps six years ago they were a danger due to poor compiler support, but these days, they're part of the language. They live under almost every piece of generic code you touch. Projects like CLang are hammering the very last nails into this coffin as we speak. They aren't a fad anymore. They aren't a magical solution. No one still thinks that. No one you should hire, anyway.
The future approaches. Do you need a Boost?
Most libraries with the buzzwords "portability framework" or "portable runtime" in their names are useless bloat and snake oil. If you want to write portable code, start with the relevant standards and follow them. Instead of reading your vendor's man pages or help files for standard library functions, read the ISO C or C++ standard or POSIX standard. And so on.
Aside from highly crippled embedded systems (note: many/most embedded systems do not fall into the "highly crippled" category) and DSPs, pretty much any environment can be made to be POSIX conformant. A much better approach than trying to design or find a new "portability framework" on top of diverse and incompatible underlying systems is to evaluate what parts of POSIX you need to get the job done, what parts might be missing or non-conformant on systems you're interested in, and whether there are drop-in replacements or workarounds for the missing or broken functionality.
For most people, the only relevant non-POSIX system is Windows. Cygwin is one heavy-weight option for making Windows conform to POSIX, but if you code to a more-inclusive subset of POSIX, you can get by with much lighter solutions and still support Windows.
There is similar Predef project on sourceforge, but it are not updated for several years also.
FWIW, the predef pages are actively maintained and have been continuously updated over the last several years.
Aside from Boost, which all C++ programmers should be familiar with, there are several libraries worth looking at. STLSoft is the first one that comes to my mind.
I have prepared a list of some prominent portability libraries for C and C++ on my personal web site. One can freely reuse it under the terms of the Creative Commons Attribution Licence. I had some experience with Qt, GLib, and the Apache Portable Runtime, and they all seemed to have been mostly OK.
There is also another list on the wikipedia.
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 willing to learn more from concurrency, and I have found this book which has many good reviews. But after taking a look at the preface, I fear that it is very focused on STD functions included only in C++11.
Since C++11 is not very used yet, and not at all at my work place, I need to know if reading this book will be a waste of time when I should be reading a different one.
I'm focusing on Windows development, but I liked the use of standard libraries to be used in UNIX and Windows both. Any recommendation or aclaration about this book?
No, book heavily uses C++11 syntax.
Also things discussed in book arent just C++11 library features, for example C++11 memory model is a brand new thing in C++11(c++98 did not recognize existence of MT).
Still IMHO you should get a super easy to install g++4.9+boost from : nuwen.net or just get VS 2013 Community.
Because C++11 is the standard and I guess soon youll start using it at your workplace (if not to quote Andrei Alexandrescu: "Call your headhunter!"). Btw std::thread and boost::thread are quite similar but with notable differences.
You are right it focuses heavily on C++11. It's "practical multithreading", as the subtitle suggests.
The only way it might interest you if you don't use C++11 is if you plan to use boost threads, which is the base of C++11 threads. But you have to know they are not exactly the same, as C++11 made some changes. ( for instance in C++11 you have to decide wether to wait for your thread to finish or leave it run on its own. In boost it runs on its own by default. If you don't choose in C++11, your program will terminate ).
Then, for your general knowledge as a C++ developper interested in its field, it is a recommended read. C++11 books are not legion for now.
The next generation of Visual C++, which is due out in a whole two weeks, includes std::thread libraries, and G++ does already if I'm not mistaken. I wouldn't count this against it. And here's the thing: C++11 is really quite essential. If your workplace isn't planning to migrate, I'd find another workplace.
Since
you are searching for a book to read on concurrency
you want to use a library that will work on both windows and unix
you want to use C++ but not C++11
you would probably need to use Boost.Thread.
There are some reasons why you would read this book then:
I don't know of a book on Boost threads
The author of this book has been the primary developer and maintainer of Boost.Thread for years
C++11 threads are a lot like Boost threads (the author writes: "Most of the examples
from the book can be modified to work with the Boost Thread Library by judicious
replacement of std:: with boost:: and use of the appropriate #include directives.")
I think it is very interesting book even if you dont know the multithread things. Like creating two mutexes in the one structure, problems when you switch from two cores to two processors. There is also a lot of design patterns. From this book you will learn in example what is ABA problem and etc. Also boost thread ( which doesnt need c++11x) are very simular to c++11 threads. You will stick with smart_ptrs, maybe sink pattern, RAII and etc. Its a wonderful book.
Be aware that even now not all features are implemented into in example G++. http://gcc.gnu.org/projects/cxx0x.html
Let be honest you sure start learn new c++, its matter of time when you will have to touch it.
I haven't read the book, but if you're not clear about concurrency, then the first thing to do is read about, use and understand one multi-threaded system.
Then do the same for another system, and take careful note of the differences from the one you already know. When you discover differences, start to read around to see how lots of different systems handle that aspect of concurrency.
If you're currently working on a multi-threaded program, then the first system you study should be the system you're primarily working on, because until you understand that system's concurrency model, you're probably breaking things and/or programming by copy-and-paste of existing code. So that's likely to be Windows, pthreads, Boost, TBB, or something else that already exists. C++11 could be a strong candidate for the second system, though.
Otherwise, I don't think it makes too much difference which one you study first. OK C++11 has the tiny disadvantage that it doesn't exist yet except as a PDF -- you'll have to install some compiler version that's still in rapid development, and maybe use Boost threads instead of std::thread for the time being, and maybe some of the code examples in the book won't compile, and you'll have to work around missing features. So don't try out experiments from the book in your work place on production code (I mean, you wouldn't anyway, right?).
To be honest, never mind C++, learning the Java concurrency model could still be a reasonable start on the path towards understanding concurrency. Or Go: that has some very nice abstractions, it will take all of half a day to get the gist of it, and it will show you how you should want concurrent programs to work, assuming no ugly complications force you to do otherwise. Sure, you're not going to use all that knowledge from Java, Go or C++11 immediately in your professional C++ work, but it might still be worth having.
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.
For a long time being a Java programmer and only hearing boost mentioned I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading. Therefore I am a little puzzled why the boost libraries are so popular?
From the perspective of someone deciding which parts of boost to get "stuck in" and learn, could programmers who use it please explain why it is so popular and the most favoured parts from the point of view of recruiters (preferably financial development)?
To make this more Stackoverflow-friendly, what are the libraries/features which make boost what it is?
I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading.
That's odd reasoning. There is a lot more to Boost than threading. Plus, just because there's a Linux library for threading doesn't mean it will work on your Windows code; Boost.Thread is cross-platform.
Allow me to hit some of the high points of Boost:
Smart Pointers
C++11 now has most of these (and improvements on them using C++11 language features). But for the past 8+ years, this was where you came for a good shared_ptr implementation. Use of these things should be mandatory where possible.
They make life in C++ so much simpler.
Regex
Not my cup of tea, and another Boost library incorporated into C++11. But if you want to do regular expression searching of strings, it doesn't get much more standard than this.
Bind and Function
Yet another thing that was incorporated into C++11, but unless you have access to a C++11 compiler/library, Boost is your best bet for this. Being able to store any kind of "callable" object in an object is incredibly useful for callbacks. And being able to adapt "callable" objects to different sets of parameters is incredibly useful, particularly with algorithms.
Filesystem
C++ has standard library facilities for opening and closing files. But nothing for looking for them or dealing with filenames. Boost does, and in a very nice API to boot. It handles platform-specific encoding through a platform-neutral interface. It allows Unicode support across those platforms that have it, etc.
Range
You know how the standard algorithms take a begin and end iterator, but most of the time you really just want it to walk the whole container? Range is here for you. It defines iterator ranges (which containers are), and it provides algorithm variants that take range objects explicitly.
What's great about Range is that the range algorithms are lazily evaluated. So you can do functional-style composition of algorithms, which works efficiently. Many algorithms return a range (which is really a range placeholder); if you feed one range into another range, you can get powerful effects with simple composition.
Variant
AKA: a type-safe union. Once you put an object of type X into it, you cannot get anything but type X out of it. Period. This is a useful tool for doing some light runtime-polymorphism work without having to use a derived class.
These are just a few of the libraries in Boost.
Boost is in part, a staging arena for proposals for the standard template library. It has strong threads solutions. However, boost also provides a wide range of other things such as containers, expression parsers... It is famous because it is a central repository for C++ non-standard libraries.
These are the libraries/features which make boost what it is. Threading is not the only thing you want to do in an application... The most "favored" depends on what you are programming, all of the libraries are useful, otherwise it would be unlikely to have been included.
Boost is just a big non-standard library collection.
C++'s STL is getting better and better, yet it's not nearly as huge as Boost (and is not intended to).
Think of Boost as a collection of useful libraries (for various purposes from math thru parsers thru containers to metaprogramming, see the docs for the list) which is known to be of good quality and just happens to be packaged together.
"boost" is just a repository of high quality C++ libs. If you write a good C++ library useful for a lot of people and which meets boost quality standard, you can ask it to be added to boost.
It happened that influent C++ programmers who are working on the C++ standards are also writers of some boost libs. Some boost libs are now standard. That makes it a central place for the C++ community.
Concerning your question about threads, boost would offer portability over using a linux-only thread lib. The boost version works on windows, too.
As a Java program you're probably used to having classes available at your fingerprints for doing a wide variety of things, from threading to XML parsing to logging to regular expressions.
The C++ core language is sparse in this regard compared to most other languages. We've got containers and algorithms, but not a lot else. Boost fills some of the gap between C++ and other languages in terms of ready-made and test libraries that we can import and useo right away rather than spend time reinventing them.
In C++11, some of the best libraries in Boost (Regex, Unordered Cntainers, Smart Ptr to name a few) are becoming part of the language. That isn't a coincidence, it's a direct result of their popularity and maturity as part of Boost.
In terms of what is most attractive, I would say a cursory familiarity with every library would be most important. Be able to say "Yes I've used boost" and "Boost.Widget" would be a good fit for this problem. Most everything else is just API reference.
If I had to pick one: Boost.Asio has definitely changed the way I think about networking. (And it's use of shared_from_this() and Smart Ptr show me new ways to think about memory management. Sorry, I guess that's two.)
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.
Hopefully this is a nice quick question to answer.
Which language is considered to be the defacto language for writing hobbyish operating systems from scratch, that also supports the creation of 512 byte boot sectors? I'm assuming plain C is the answer, although I have this vague concept in my head that C++ can also be used. Do any of you have any opinions about alternative but potentially superior languages, given the passage of time? Would others highly suggest plain old assembler?
And, following on from your answer, what free (and perhaps even open source) compiler would you recommend for compiling the source code into binary?
PS: I am fully aware that writing an OS is a very challenging task and I'm sure I'll never finish. I am conducting a personal-interest research task and would like to at least create a MBR and very basic kernel with simple console IO.
I'd say C (and GCC specifically) is the most commonly used compiler for this purpose.
Most modern compilers don't support "segmented 16-bit" anymore, and none are really good for dealing with limitations like "this code must fit in 512 bytes" or handling things like CPU mode switches and unusual situations. For these reasons people that write their own boot loaders for "PC BIOS" (as opposed to using something like GRUB) tend to use a dialect of assembly (NASM, FASM, GAS).
This doesn't mean other languages (and other compilers) can't be used; and I have seen people write kernels in a wide variety of languages (Pascal, C++, C#, etc). It is also limited to the low-level code (e.g. boot code and kernel). Once you get beyond that, you can use almost anything for higher pieces (drivers, file systems, GUI, applications). There's also some people that invent their own languages to use for the kernel and/or higher pieces of the OS.
I do have an opinion about alternative but potentially superior languages. My opinion is that "potentially superior" doesn't justify the high "Tower of Babel" costs (where most programmers can't read most source code because of language differences) that the existence of many different languages is having on the IT industry as a whole. For an OS project, an alternative language might have theoretical advantages, but in practice those advantages are outweighed by the disadvantage of reducing the number of people who are familiar with the language and could volunteer to help (either when you get stuck and need help with bugs, etc; or later when you need volunteers to contribute thousands of drivers).
I do use plain old assembler (for boot code, kernel code, drivers, etc). I do not recommend it; unless you're much more experienced with assembly than any other language AND you have other reasons for not using a higher level language AND portability won't become an issue.
I'd probably recommend GCC (as a free and open source compiler to use for compiling most of the different/separate binaries that make up an OS project). However, I'd also recommend avoiding the use of non-standard language extensions and any "implementation defined" behaviour (regardless of which language and which compiler you use), so that you can switch to any other compiler at any time (for any reason) more easily.
C and Assembly.
For C compiler I recommend gcc compiler.
For X86 assembly I recommend nasm assmebler. You can also use gas which comes with gcc, if you prefer AT&T syntax over intel syntax.
The boot sector has to be written in assembly.
The kernel can be written in any language. You probably need assembly there, but you can also use higher level languages (like C) if you like.
If you want something very simple you can write it all in assembly.
For more information: http://wiki.osdev.org/Main_Page
I'd start with linux because a lot of the open source stuff you will need to port for basic functionality will have been written for that platform.
I got as far getting newlib, http://sources.redhat.com/newlib/ because it is easier to implement than gclib but not as good and then thought, I am building Linux again and switched to using other peoples'.
As for free compiler, they are pretty much all free on Linux. As others here mentioned gas or as are assemblers but setting up cross compilation and choosing your executable format may well need to be accomplished before settling on a final tool set. For reasons of reliability, speed, and porting 3rd party apps over, I would aim to implement a build environment on my custom OS and this might prevent higher level coding tools coming to the fore. Hence you really need to be looking at tools that you can build yourself from source code. Linux from Scratch ( http://www.linuxfromscratch.org/lfs/ ) is a great introduction to cross compilation- same architecture, different (cross) environments.
There were serious obstacles to implementing gclib on a scratch built OS, but that was just my experience around about 3 years ago so things may have changed, and the number of platforms portable code would need to target has certainly increased dramatically.
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 9 years ago.
So, I've been reading through and it appears that the Boost libraries get used a lot in practice (not at my shop, though). Why is this? and what makes it so wonderful?
Boost is used so extensively because:
It is open-source and peer-reviewed.
It provides a wide range of platform agnostic functionality that STL missed.
It is a complement to STL rather than a replacement.
Many of Boost developers are on the C++ standard committee. In fact, many parts of Boost is considered to be included in the next C++ standard library.
It is documented nicely.
Its license allows inclusion in open-source and closed-source projects.
Its features are not usually dependent on each other so you can link only the parts you require. [Luc Hermitte's comment]
From the home page:
"...one of the most highly regarded and expertly designed C++ library projects in the world."
— Herb Sutter and Andrei Alexandrescu, C++ Coding Standards
"Item 55: Familiarize yourself with Boost."
— Scott Meyers, Effective C++, 3rd Ed.
"The obvious solution for most programmers is to use a library that provides an elegant and efficient platform independent to needed services. Examples are BOOST..."
— Bjarne Stroustrup, Abstraction, libraries, and efficiency in C++
So, it's a range of widely used and accepted libraries, but why would you need it?
If you need:
regex
function binding
lambda functions
unit tests
smart pointers
noncopyable, optional
serialization
generic dates
portable filesystem
circular buffers
config utils
generic image library
TR1
threads
uBLAS
and more when you code in C++, have a look at Boost.
Because they add many missing things to the standard library, so much so some of them are getting included in the standard.
Boost people are not lying:
Why should an organization use Boost?
In a word, Productivity. Use of
high-quality libraries like Boost
speeds initial development, results in
fewer bugs, reduces
reinvention-of-the-wheel, and cuts
long-term maintenance costs. And since
Boost libraries tend to become de
facto or de jure standards, many
programmers are already familiar with
them.
Ten of the Boost libraries are
included in the C++ Standard Library's
TR1, and so are slated for later full
standardization. More Boost libraries
are in the pipeline for TR2. Using
Boost libraries gives an organization
a head-start in adopting new
technologies.
Many organization already use programs
implemented with Boost, like Adobe
Acrobat Reader 7.0.
A few Boost classes are very useful (shared_ptr), but I think they went a bit nuts with traits and concepts in Boost. Compile times and huge binary sizes are completely insane with Boost, as is the case with any template-heavy code. There has to be a balance. I'm not sure if Boost has found it.
It adds libraries that allow for a more modern approach to C++ programming.
In my experience many C++ programmers are really the early 1990s C++ programmers, pretty much writing C++ classes, not a lot of use of generics. The more modern approach uses generics to compose software together in manner thats more like dynamic languages, yet you still get type checking / performance in the end. It is a little bit ugly to look at. But once you get over the syntax issues it really is quite nice. Boost gives you a lot of the tools you need to compose stuff easily. smart pointers, functions, lambdas, bindings, etc. Then there are boost libraries which exploit this newer way of writing C++ to provide things like networking, regex, etc etc...
if you are writing lots of for loops, or hand rolling function objects, or doing memory management, then you definitely should check boost out.
BOOST's a collection of libraries filling needs common to many C++ projects. Generally, they do prioritise correctness, reusability, portability, run-time performance, and space-efficiency over readability of BOOST implementation code, or sometimes compile times. They tend not to cover complete high-level functional requirements (e.g. application frameworks), and instead (thankfully) offer building blocks that can be more freely combined without dictating or dominating the application design.
The important reasons to consider using BOOST include:
most libraries are pretty well tested and designed: they generally get a reasonably sound review by some excellent programmers, compared to by people with home-brew solutions in the same problem space, and widely used enough to gather extensive real-world feedback
it's already written and your solution probably isn't
it's pretty portable (but that varies per library)
more people in the C++ community will have a head-start in helping you with your code
BOOST is often a proving ground for introduction to the C++ Standard, so you'll have less work to do in rewriting your code to be compatible with future Standards sans BOOST
due to the community demand, compiler vendors are more likely to test and react to issues of correctness with BOOST usage
familiarity with boost libraries will help you do similar work on other projects, possibly in other companies, where whatever code you might write now might not be available for reuse
The libraries are described in a line or two here: http://www.boost.org/doc/libs/.
Because the C++ standard library isn't all that complete.
Boost basically the synopsis of what the Standard will become, besides with all the peer review and usage that Boost gets you can be pretty sure your getting quite a good deal for your dependencies.
However most shops don't use Boost, because its an External Dependency. And in reality reducing External dependencies is very important as well.
Anything with Kevlin Henney's involvement should be taken note of.
Boost is to C++ sort of like .NET Framework is to C#, but maybe on a smaller scale.
I use the filesystem library quit a bit, and the boost::shared_ptr is pretty nifty. I hear it does other things too.
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.
C++ was the first programming language I really got into, but the majority of my work on it was academic or for game programming. Most of the programming jobs where I live require Java or .NET programmers and I have a fairly good idea of what technologies they require aside from the basic language. For example, a Java programmer might be required to know EJB, Servlets, Hibernate, Spring, and other technologies, libraries, and frameworks.
I'm not sure about C++, however. In real life situations, for general business programming, what are C++ programmers required to know beyond the language features? Stuff like Win32 API, certain libraries, frameworks, technologies, tools, etc.
Edit: I was thinking of the standard library as well when I said basic language, sorry if it was wrong or not clear. I was wondering if there are any more specific domain requirements similar to all the technologies Java or .NET programmers might be required to learn as apposed to what C++ programmers need to know in general. I do agree that the standard library and Boost are essential, but is there anything beyond that or is it different for every company/project/domain?
As for every language, I believe there are three interconnected levels of knowledge :
Master your language. Every programmer should (do what it takes to) master the syntax. Good references to achieve this are :
The C++ Programming Language by Bjarne Stroustrup.
Effective C++ series by Scott Meyers.
Know your libraries extensively.
STL is definitely a must as it has been included in the C++ Standard Library, so knowing it is very close to point 1 : you have to master it.
Knowing boost can be very interesting, as a multi-platform and generic library.
Know the libraries you are supposed to work with, whether it is Win32 API, OCCI, XPCOM or UNO (just a few examples here). No need to know a database library if you develop purely graphic components...
Develop your knowledge of patterns. Cannot avoid Design Patterns: Elements of Reusable Object-Oriented Software here...
So, my answer to your updated question would be : know your language, know your platform, know your domain. I think there is enough work by itself here, especially in C++. It's an evergoing work that should never be overlooked.
C++ developer have to grok std and boost libraries.
List of other technologies largely depends on project type. For sure you will have some interaction with SO, so you will need to know API of your environment.
As for data-access and other stuffs there are tons for different solutions. C++ is much richer than some managed langs in that sense. 99% of old popular systems have C/C++ interface.
After you clarified your question a bit in the comment to my answer I can recommend:
Good code browser (SourceInsight or Understand For C++ for example)
Static analysis tools (Link, KlockWork Inforce, etc.)
MySQL\SQLite (I encountered these DB in a huge number of C++ projects)
UI technologies (OpenGL\GLUT, DirectX, GDI, Qt, etc)
technologies you should know as a C++ programmer (and therefore more technically knowledgeable than lesser programmers ;) ):
performance issues - what makes things go slow, how to find and fix such issues. I also mean stuff like context switching, cache lines, optimised searches, memory usage and constraints, and similar stuff that your average VB/C# developer doesn't care about.
threading issues - how to get the most from a multi-threaded app, how to detect and fix abuses of the same.
low-level communications - especially being able to connect to obscure systems that no-one else has written a toolkit for (especially radio comms), latency and bandwidth management.
Otherwise, for specific tools - it depends on what you're targeting, Windows dev will be different to Linux, different to embedded.
This will largely depend on the used platform and other constraints. As a general rule, a good (C++) programmer is (or should be) able to learn a platform-specific API in a very short time. For C++, it's much more important to understand the different tool chains (e.g. a Windows programmer should also know the GCC tool chain) and differences in compilers. Programmer should also understand limitations and platform-dependend behaviour of the language.
As for libraries, C++ programmers absolutely need to know STL and Boost. No discussion.
Standard Template Library
http://en.wikipedia.org/wiki/Standard_Template_Library
Besides the stuff everyone listed, keep in mind that C++ programmer have space on the embedded systems market (much more than most other high level languages).So familiarity with embedded systems and development may open a lot of doors and job opportunities where you will not be competing so heavily with Java development for example. So learning to code compact code (compact after compiled) and low memory usage techniques is a good bet.
if you're using gcc you should definitely know gdb. Actually, you should be proficient with the local debugger for whichever compiler you're using. Other than that there is such a wide range of libraries used that being able to quickly pick up an API is more useful than any specific one. I would suggest learning doxygen though.
If you are using linux then Valgrind is a very usefull tool for checking how your program deals with memory access.
In no specific order
COM/ATL
DirectX
MFC & Win32
STL
GDI
BOOST
The popular way to use C++ in the mobile space would involve learning Symbian OS development.
http://developer.symbian.com