Comments

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.

Thanks.

Thanks STL and Charles for this.

17 hours ago, Charles wrote

[C64] It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.

Really?

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.

@Charles:Yes, I watched the presentation.

If such a complex feature is going to be pervasive and is a must to be learned for C++ devs, I'm not sure that would be good for the language and its adoption.

It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.

@Ben Hanson:

1 hour ago

>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.

@Ben Hanson:

28 seconds ago

@C64:

>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,

It is important to pay attention to not cross a "read-only/write-only complexity level". 

[...] I would argue that it is advanced features and uncompromising performance that ultimately keeps C++ relevant.

I think C++ gives very good performance and also offers good abstractions.

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.

Thanks for sharing this video on C9.

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?

10 hours ago, Charles wrote

@AceHack: Indeed. Slowly but surely. Stay tuned!

C

Great !

Excellent Q&A! Thanks Charles/Channel 9 and C++ gurus.

5 minutes ago, windev wrote

@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).