Very good interview! Thanks both Pedro and Charles.
One thing I'm curious is what development tools you guys in the kernel world use.
We in the user mode world use Visual Studio with its convenience and facilities; but when you are writing code for the kernel, what are your tools? What editors do you use? What debuggers? Is there a special build of the C compiler for kernel mode, or do you use our classical "user mode" cl.exe?
A video on "development tools for kernel mode devs" would be interesting.
[C64] It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.
Sure. Just an example: I use STL classes like std::vector and std::map, and I almost completely ignore template metaprogramming (things like std::enable_if, etc.). I don't know if inside STL implementation it is used, but as an STL client, I can just ignore it.
>I agree with you that we can't have super-easy >programming languages; but I think that crossing some >high-complexity line is not good.
I agree that there surely is a threshold. Quite where it lies is debatable.
Yes, probably this is the key point
>But when, after benchmarking, we identify some hot spots >and want to make the performance better, we can always >use low-level pure C or even manually crafted assembly >code in those particular cases.
And this is the best we can do in the 21st century? Your approach to C++ feels more and more like "C with classes". If that is the case, then we will simply have to agree to disagree.
I consider programming languages just as tools to solve problems, and if the assembly language is the best tool for the job in a particular case (e.g. top performance in some hot spot), I have nothing against it (and if in other cases the problem can be solved with Python, I can use it, etc.)
As for my approach for C++, I like that we don't have to be language-lawyers to be productive with this language: we can choose a "safe" subset of it and use it. I don't know what you exactly mean with "C++ as C with classes"; I like using C++ classes, including the power of destructors, smart pointers (e.g. CComPtr is convenient to do COM programming), template for containers but not for template metaprogramming, etc.
As I wrote in the beginning, there are convenient constructs in C++11, like auto, lambdas, etc. that can simplify the code. I think it's possible to use C++11 enjoying these convenient features and ignoring the more "obscure" parts.
>but pointer semantics (and in fact they prefer raw pointers T* to T&, >like explained in Google's C++ Style Guide)
Please don't quote the Google C++ Style Guide - it is totally boneheaded.
While I don't agree with every point of that style guide, I respect that guide and I think great software was built using it (starting from the search engine used by billions of people worldwide).
While with the help of Intellisense the reference parameters can be accepted, if you read plain source code I think having a form of syntax to specify at the call site that a parameter is going to be modified and a pointer is actually passed is a good point.
>but now with the addition of rvalues things got much more complicated.
Yes, things are definitely more complex! [...] Rvalue references do give you pause, I agree. I'm confident that things will get smoothed out over time however.
I hope so
In general, I view the attitude that every programming language "should be as easy as Visual Basic" as so much noise.
I agree with you that we can't have super-easy programming languages; but I think that crossing some high-complexity line is not good.
Keep in mind that code must be maintained, so its clarity is a very important point.
For example, remaining in the domain of C++98/03, I think template metaprogramming kind of crossed an high-complexity line: writing, and especially maintaining and debugging template metaprogramming code is an highly complex (and error-prone) job,
Scott seems clearly a master in C++: he knows the subject inside out. But to me these C++11 rvalue things seem very complicated.
There are other C++11 features that help simplifying code, like using auto for iterators, or range based for loops, or lambdas (which play very well with STL and allow us to write simpler code instead of defining functors in contexts like remove_if(), etc.), but this rvalue argument is complex.
It may be worth noting that some C++ programmers already find C++98 non-const lvalue reference confusing with their value syntax but pointer semantics (and in fact they prefer raw pointers T* to T&, like explained in Google's C++ Style Guide), but now with the addition of rvalues things got much more complicated.
C++ code can already be complex, and it may be kind of scary to debug some complex C++ code with the addition of these universal references, rvalues and related rules (I sometimes think that these help [time 00:37:29] "Keeps people like me [Scott] in business"
I'd like to watch some video or read some doc showing how rvalues can be used by the "practical" (non-language-lawyer) C++ programmer, or maybe rvalues are too much complex and remain in the domain of the language lawyers?
@C64: Visual Studio 2008 SP1 is used to compile the tools so that the tools use MSVCRT v9.0 - which is shipped with Windows XP/Windows 2003.
I can be wrong, but using Dependency Walker I see no dependency of PROCEXP.EXE on MSVCR90.DLL, so I thought Sysinternals tools used static linking to CRT (which to me makes sense, to make tools deployment easier).
Thanks Mark and Channel 9 for the very interesting talk!
And yes: Process Explorer is excellent!
@Mark: It would be great if you could make Sysinternals tools open-source (e.g. sharing the source on CodePlex), so the community could both learn advanced Windows native programming techniques from your code and also contribute to code with additional features.
Moreover, an analysis with depends.exe shows that Linker Ver field for procexp.exe is 9.0, meaning that Visual Studio 2008 (VC9) was used to build this tool. I'm curious why do you use this particular toolset (e.g. to support older OS'es like Windows 2000)?
Thanks, and please keep up your excellent work on Sysinternals tools.
DevDiv: the closer you stick in using C++ in the IDE, the better will be for us VS IDE users. Since the adoption of .NET with VS2010, the IDE does have performance problems.
C# is a very good tool if you want to optimize for programmer's productivity (I enjoyed using it with WinForms to build some database front-ends), but for projects like VS IDE you have to go native and use optimized C++ to offer a quality experience for the UI: fast start-up times, snappy UI also for large solutions, etc.
In Microsoft you have stellar C++ devs (just as an example: STL is famous here for his quality lessons): please make some of them at work for the VS IDE.
(Or in the meantime you may make it possible to use the new improved C++11 compiler and libraries with older faster IDEs like VS2005/2008.)