Is coding in native c++ still popular? [closed] - c++

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.
I want to go into native c++ programming after University, but it seems like languages that compile with JIT (like .Net) are overtaking c++. What does the future hold for Native code?

C++ is the seventh programming language I have been professionally paid to program in, and I'm sure won't be the last. My advice is not to think of yourself as a specific language programmer. Even if JIT takes over the world, it has to get down to native machine code eventually, and someone has to write that software.

There are a lot of opportunities to work on natively compiled C++ code. It's especially popular (along with C) in non-PC environments such as embedded and real time environments, and in a lot of situations where there is some level of safety certification required.
Game programming, where performance is usually critical, is another area where C++ is very popular.
It is less popular than it was in traditional 'desktop' applications and web service applications although you can find native code projects in both these areas - especially the former - if you hunt around.

I'm not sure what you mean when you say that you will be "going into native C++ after college". Your career will not be defined by what languages you know, it will be defined by what you can do with those languages.
However, C++ is used widely in many applications. I work in systems and we use C++ for everything. .NET isn't an option in my world, but the guys doing the GIU's next door use it for everything. It comes down to what you want to do with your career. The language you use will come naturally, you are thinking about it backwards.

There will always be a place for C/C++
Any application that needs to be as
fast as possible will be written in
a native language like C/C++
Any application that runs on a device that has limited memory
will
run better in C/C++ since memory
management is more deterministic.
Operating systems will continue to be written in C. That
include
device drivers.
Up until recently one always had the luxury of speeding an application up by using better hardware. Will Moore's law being stretched to the limit, chances are the performance improvements will have to come from software. Chances are that languages that give better performance will come into their own in this regard.

If you go desktop C++ is still the way to go especially if you want to be cross platform.
Java GUI Libraries are way to slow and .NET is not portable (the GUI part).
But C++ is a language beast, the only language where i can understand managers to ask for 5 years experience.
In the server world the VM/JIT has so many advantages that only basic infrastructure is coded native. If this is the industry you want to join learn (infrastructure) or don't learn (applications) C++.
Its also pretty popular in embedded programming where you can't fire up a hundert MB virtual machine.
Since C/C++ is the only fast imperative native programming language left in mainstream you should learn at least the basics.

Yes, of course it is:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
And some of the great features like rvalue-references, variadic templates, uniform initializations, lambdas, unrestricted unions, thread-local storage, extern templates and ... yet keeps C++ to be a good choice for 20 years of the future, until the C++ committee decides to publish another new standard for the other remaining years (like a do...while!) (:
Note that the computers needs native programs to run! Java, .NET, python and ... needs native environment to run on it! so, native programs are the base of softwares.

Related

What is the advantage of using the native C++ Qt over PyQt [closed]

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 want to develop in Qt, and I already know Python. I am learning C++, so what are the advantages of programming Qt in C++ over Python? C++ seems more complicated, and seems like there is not much gain.
What is the advantage of using the native C++ Qt over PyQt
Speed/power/control.
PyQt application will still require python. C++/Qt Application compiles to native exe. By using C++ you'll get access to 3rd party libraries that won't be available in python, plus you'll exterminate "middle man" - layer that sits between your program and qt dlls and potentially you can get better performance. For example, I would not write an archiver or mp3 decompressor in python, although it certainly can be done.
However that comes at a cost - c++ does not have a garbage collector, is much more complex, has "slower" development (compilation time), requires years to master and you'll get better performance only if your bottleneck is in within interpreter (i.e. scripted language overhead). I.e. C++ gives more power at a cost of greater responsibility and longer development time. If you don't need that, then you don't have a reason to stick with C++.
Choice of language depends on your application/situation and your personal preferences. If you need to make application SOON or make a mockup, then it'll be reasonable to use language you're familiar with. If you have serious performance problems, then it'll be reasonable to hire skilled C++ programmer to do the job - make native application, profile it, optimize, etc.
Please note that language is a tool. If you want to use your language for everything simply because you like the language, you're not working efficiently.
--EDIT--
Personally, I would not use python for a larger application I'm expected to maintain for a long time. However, this is because the language is not exactly compatible with my mindset (reliance on Murphy's Law) and (as a result) I'm not comfortable with it. Person that thinks differently will be probably much more comfortable with Python and might even think that C++ is too restrictive.
Another thing is that judging from my experience of writing Blender plugins and various python scripts, there's some serious performance overheads that appears because language is scripted, and very heavy list/map/array manipulation that can be performed FAST for free in C++ might take 5x..10x times longer in python. Some people might insist that this can be fixed, however, cost of this "fixing" might overcome benefits you get from using scripted language. Regardless of my preference, I still use Python for making utility scripts that need to run several utilities, split/splice/parse their text output and do something with it (C++ isn't very good at this situations), and I'd still provide Python bindings (assuming Lua is no good) in a program that must be extensible.
In the end it comes down to selection of most suitable tool - if C++ will not give you any benefit compared to Python, then there's no reason to switch.
If you're planning on distributing your app, it's much easier to deliver a self-contained compiled executable than relying on your end users to install Python and PyQt first. But that may or may not be a consideration for you.
C++ optimizes machine speed.
Python optimizes programmer speed.
C++ is relatively wordy: more words per idea expressed. Bugs / Lines_of_code is roughly a constant, so concision matters.
C++'s memory management is sometimes manual, which can mean strange runtime issues http://stromberg.dnsalias.org/~strombrg/checking-early.html including segfaults and memory leaks. Python takes this out of the hands of the programmer and automates it.
GUI's rarely care about the speed of their implementation language - the main issue is how fast the enduser can type and click.
In short, I believe that unless you have strong performance requirements, you should stick with Python. Also, as Greg mention, your program will be more portable with Python than with C++.
I love C++ but these days, for most project, I mostly turn to Python if not Java. However, if I'm writing a game or a graphics application, I might consider C++.

Why Was the GObject System Created? [closed]

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.
The Introduction
Okay, so after version 0.60 of GTK+, the designers realized that for future development and progress, the entire toolkit needed to be rewritten to be object-oriented.
Now, since C doesn't support OOP, to provide object-orientation and in inheritance heiriearchies, they created the GObject System. Now creating the GObject System must have required development time, more dependencies, more problems, but they had to create it to provide object orientation capabilities to the C Programming Language. But at that time, there was another solution that provided exactly that, C++!
The Question
Why didn't the developers of GTK+ just use C++?
The Explanation
I mean, Why waste time creating an entire library instead of using a time-tested solution adopted by a lot of projects? Don't get me wrong, I am not trying to turn this post into a C vs C++ thing (I've had enough of that on forums, thank you). I just want to know the reasons and issues that made the designers of GTK+ make the decision they did.
I can't directly answer the question, at least as far as GTK goes. That answer lies with the GTK+ developers, so you'll have to hunt them down and ask them. But as for why one would want to add an object oriented system to C, instead of using C++, there are plenty of reasons. The three I would immediately think of are
Language Complexity: While C is a pretty simple language, C++ is mind-numbingly complicated, with support for most (not all) C stuff, as well as conveniences like references, and also object-oriented features and a complex template language. And have you seen the new system of values: lvalues, rvalues, glvalues, prvalues and xvalues - huh? There's plenty more I could talk about. Given time, C++ becomes manageable, but it's still overkill for just wanting some object oriented features in C.
Control: If the designers went with C++, they'd be stuck with C++ philosophy. For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies. If the designers went with C++, there would be no way to limit users to a single inheritance system. Multiple inheritance is just an example - I'm sure there's plenty of other places in which the GObject system differs from the C++ ideology.
Interoperability: This is probably a big one. Although there a few languages with which C++ interoperates cleanly, the fact is that C++ just isn't that great at interop. However, interoperability with C is almost taken for granted. C is often described as the lingua franca of programming languages, since it forms the de facto standard for interop. By designing a C API, the GObject designers opened the door to GTK+ development in any number of languages.
GObjects is intended to be language independent. It has dynamic typing, and you should it compare with a run-time system like COM, .NET or CORBA, rather than with specific languages. If you go into languages, then the features are more at the Objective-C than the C++ side.
The GObject type system does things that you can't do in C++. For one thing, it allows creation of new classes at runtime, and does this in a way that is language-independent - you can define a new class in Python at runtime, then manipulate instances of that class within a function written in C, which need not even be aware that Python was ever involved.
From the wiki linked to in the question:
History (From Wikipedia)
GTK+ was originally designed and used in the GNU Image Manipulation Program (GIMP) as a replacement of the Motif toolkit; at some point Peter Mattis became disenchanted with Motif and began to write his own GUI toolkit called the GIMP toolkit and had successfully replaced Motif by the 0.60 release of GIMP.[3] Finally GTK was re-written to be object oriented and was renamed GTK+. This was first used in the 0.99 release of GIMP.
This should tell you that object-oriented paradigm was not a paramount criterion for the choice of language for GTK (which is different from GTK+) and that feature was added much later.

The advantages and Disadvantages between C++ and VB6 [closed]

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.
I would like to know the advantages and disadvantages between C++ and VB6. The reason I am asking is because I came across a website where they have source code for various programs that are coded for Windows machines, and they are almost all coded in VB6.
However, I do not know a lot about VB6, and am trying to learn C++ at the moment, and I was wondering why people would code in VB6 instead of C++ or how they rank in different areas.
So I would appreciate it if someone could weigh the pros and cons of each language and really give me perspective of the languages.
-Oswald.
I was wondering why people would code
in VB6 instead of C++ or how they rank
in different areas.
VB6 is a dead language. It was a Microsoft proprietary language.The VB6 IDE is no longer supported but VB6 applications are supported for at least the lifetime of Windows 8. Most (with many changes) of the syntax lives on in VB.NET (another proprietary language). In addition to the syntax, VB.NET and VB6 share the idea of "canned programming", where the developer just combines existing building blocks to create small applications very easily. VB6 introduced a large number of innovative techniques for this. It became known as RAD, Rapid Application Development or Rabid Application Development, depending on who you ask.
The problem with RAD, that it doesn't scale…
Probably you looked at a very old web site.
C++ is a general programming language standardized by ISO. There are also a great many other general programming languages, and many of them are also standardized. In addition there are general programming languages like Java that are not standardized by some international standards organization, but have sufficient heavy backing that it's almost as if they are open languages, in spite of being technically proprietary.
Going into more details comparing the languages serves no useful purpose.
You might read up on the old C versus Pascal debates to see why (these debates got pretty heated, so called language wars, but resulted in some classic papers such as Brian Kernighan's "Why Pascal is not my favorite language").
VB6 is antiquated -- the only reason people would code in it these days is if their company had business reasons for not upgrading to something newer (like a large legacy code-base written in VB6). Even then, you'd expect them to be looking to move on.
VB6 has been obsolete for quite some time now and superseded by VB.NET. C++ and Visual Basic have way too many differences to list here, but if you want to learn C++, it doesn't help much to learn from VB examples. There are plenty of books, tutorials and examples for C++ - in all likelihood, much more than what you would find for VB - so that's what you should be looking for.
I am learning C++, but only after Python and Java.
It is not suggested to learn C++ as a first language (that's what I got online).
I am interested in getting deeper in low-level programming an OSs so C/C++ is what I am aiming for right now.
I would say learn C++
One reason VB may still be used is that in some companies (such as the one I worked for) we required financial analysts who were good at understand the math behind the business AND be able to produce applications that solved business problems. It turned out (as others have pointed out above) that it was easier for us to hire folks with good functional business knowledge and then get them up-to-speed with VB than C++ or VC++, the latter two being the exclusive domain of the IT-department developers.
Basically if you are looking for low-level coding that offers more speed then go with C++, however if you are new to programming I wouldn't recommend it. However, there is much more overhead with C++ and coding can take more time. C++ also allows you to be object oriented if you so choose, but it does not force the paradigm.
Visual Basic is a high-level language and is pretty well noob friendly but is slower than C++. Visual Basic has less overhead meaning you can code a lot quicker once you get the hang of it. I'm not sure if VB is object oriented but I don't believe so.
C++ is a lower-level languagge, thus programs will perform better... everywhere, period.
VB6 is a higher-level languagge, so it'd probably be easrier to learn. Actually it would depend on your previous skills, if you know java you'll have a hard time understanding VB6.
A friend of mine once said, if you know english you can write VB6 :)
Plus, VB6 is no object-oriented, while C++ is
VB6 has since been superseded by VB.net. VB was and continues to be very "newbie" friendly. VB was easier(depends on what and whom you ask) to code in, whereas C++ allowed access to certain components not available in VB6. C++ was also significantly faster than VB6, though those type of speed differences don't matter much any more.
There are certain sites which continue to host/advocate vb6 code. VB6 support will be completely dropped after Windows 7.
So the main difference is that VB6 is a slower, (becoming unsupported), proprietary language that is easier to learn for programming beginners. C++ is a standardized, supported language that's quite a bit harder to learn, though its faster/more efficient.
For starters, I'd recommend a Basic dialect, be it Microsoft Small Basic (this is a newb's language), VB.net, FreeBasic, RealBasic, Auto-it or maybe even PowerBasic.
Hope this helps.

Will Learning C++ Help for Building Fast/No-Additional-Requirements Desktop Applications? [closed]

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.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.

What technologies do C++ programmers need to know? [closed]

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