In today’s world, there are so many programming languages to choose from when developing software projects. So, oftentimes, this question arises: “With so many simpler and higher-level programming languages, why should I choose C++ to do X?”
Well, programming languages (and frameworks) are just tools. And my usual guidance is: use the right tool for the job. So, if for your project a simpler/more productive/higher-level programming language is well suited, then just go for it!
But, there are cases in which C++ is just The Best Tool For The Job.
One of these contexts is the development of in-process shell extensions for Windows. There is a whole MSDN web page discussing “Guidance for Implementing In-Process Extensions”.
A key point is that the .NET Framework/CLR is a high-impact runtime, with associated performance issues for in-proc extensions:
The aforementioned MSDN documentation continues with a brief discussion of issues associated to high resource consumption as well.
Then, another paragraph about “Issues Specific to the .NET Framework” briefly touches on COM interop related problems. It’s important to keep in mind that the in-proc shell extension model was designed around native code, and there is a kind of “impedance mismatch” between that and the managed .NET world.
Note that the use of .NET is considered acceptable for other types of extensions, like out-of-process extensions.
A common type of shell extensions are the context-menu extensions.
If you are curious about the development of this type of extensions using C++, you may find my Pluralsight course on the subject interesting.
(A brief description of the course content is offered in this blog post.)