FAQ: The C++ Debate

Many people from Microsoft, including the DDK support team (the folks you talk to during DDK support calls) strongly recommend that drivers be written in pure C. However, it is difficult to find an official, unequivocal quote from MS to this effect. As a result, C++'s suitability for KMDs is the subject of a rather spirited ongoing debate, with Microsoft (at least by reputation) and those who prefer sticking to MS-recommended environments on one side, and those who really don't want to give up the perceived benefits of C++ classes and etc. on the other. Here is what I hope is a fair presentation of the arguments presented by both sides.

In the early days of WNT development there was a conscious decision to not use C++ in kernel mode. This due to concerns both for the correctness of the compiler, and for efficiency of the generated code. Also, there was very little perceived benefit, and considerable perceived cost, in adding additional layers of abstraction on top of those provided by C.

The C++ RTL (like much of the C RTL) cannot be used in kernel mode, let alone from IRQL >= DISPATCH_LEVEL. C++ driver writers will therefore have to provide their own replacements for new and so on.

Assuming that that has been done, it is obviously possible to write a driver in C++ and make it work correctly. No one is claiming that use of C++ language features is guaranteed to break drivers.

Mark Roddy of OSR correctly points out that simply using the compiler in "C++ mode" (by renaming your .C file to .CPP) causes it to be far more fussy about type checking, and argues that this improves the driver's reliability even if it doesn't use any C++ syntax.

Microsoft's documentation plainly states (in the NT Version 4 DDK, "Kernel Mode Drivers", "Design Guide", section 1.2.1) that drivers should be written in ANSI C. However, the focus of this section is "Portability," and the main concern expressed in the text is that the driver be source-portable across processor architectures (x86 to Alpha). Microsoft has not (anywhere that I've found) described specific problems that have arisen from attempting to use C++ in drivers.

As far as their own code is concerned, Microsoft appears to not be completely inflexible on this issue. GDI32 was originally written in C++ in user mode but was ported to kernel mode as of NT 4. Also, the NT5 (Win2K) Beta 2 DDK includes a sample audio streaming driver written in C++.

A primary concern that has been widely expressed is that many of the C++ mechanisms need to generate some automatic storage that is not seen by (and therefore not under the control of) the programmer. Since kernel stack space is at a premium in kernel mode, this is a valid concern, but it is difficult to quantify.

The extra "layer" of calls to virtual functions will obviously place extra call frames on the stack, and take extra time as well.

At least two commercial products exist that provide C++ class libraries that "wrap" the NT KMD environment. It is safe to assume that if anyone had had problems with them, especially "showstopper" problems involving their use of C++, the fact would have been publicized and widely discusssed in the relevant newsgroups. No such problems have been reported in the over two years that these products have existed.

I would argue that if you're going to use C++ it would be of great benefit to use one of the existing C++ support products. (See the Related Products page.) These vendors have already done the work to implement kernel mode-safe replacements for the C++ support RTL.

My final argument against C++ is more practical than technical: Microsoft has in the past steered strictly away from it in kernel mode, and there are still far more kernel mode source modules, and especially driver source modules, of type .c than of type .cpp . Now MS does a complete build of NT from source (including all drivers) at least once a day, and many, many developers within MS build drivers many times each day. So, when it comes to code that will run in kernel mode, MS tests their new versions of the compiler far more thoroughly in "C mode" than in "C++ mode". So even if a driver compiles correctly under the current compiler, I have far less confidence as to what will happen under future compilers if the source is in C++.

Of course I can't prove that there will be a problem with C++ code in kernel mode under a future compiler version. My issue is that if I stick to C, MS claims there won't be a problem, and they make no such claims for C++.

I must confess that I'm one of those who frankly doesn't see a compelling advantage, either in portability or in code safety, for C++, so you should evaluate my "stick to C" opinion in that light.

On the other hand, the C++ proponents have quite a vested interest (in terms of code shipped to customers) in their position. So, as a famous witness for the prosecution once said in a British court, when told that the defense denied all charges... "Well, they would say that, wouldn't they?" That should be kept in mind when reading their arguments.

top of page | up | previous | next | home




	FAQ: The C++ Debate Many people from Microsoft, including the DDK support team (the folks you talk to during DDK support calls) strongly recommend that drivers be written in pure C. However, it is difficult to find an official, unequivocal quote from MS to this effect. As a result, C++'s suitability for KMDs is the subject of a rather spirited ongoing debate, with Microsoft (at least by reputation) and those who prefer sticking to MS-recommended environments on one side, and those who really don't want to give up the perceived benefits of C++ classes and etc. on the other. Here is what I hope is a fair presentation of the arguments presented by both sides. In the early days of WNT development there was a conscious decision to not use C++ in kernel mode. This due to concerns both for the correctness of the compiler, and for efficiency of the generated code. Also, there was very little perceived benefit, and considerable perceived cost, in adding additional layers of abstraction on top of those provided by C. The C++ RTL (like much of the C RTL) cannot be used in kernel mode, let alone from IRQL >= `DISPATCH_LEVEL`. C++ driver writers will therefore have to provide their own replacements for `new` and so on. Assuming that that has been done, it is obviously possible to write a driver in C++ and make it work correctly. No one is claiming that use of C++ language features is guaranteed to break drivers. Mark Roddy of OSR correctly points out that simply using the compiler in "C++ mode" (by renaming your `.C` file to `.CPP`) causes it to be far more fussy about type checking, and argues that this improves the driver's reliability even if it doesn't use any C++ syntax. Microsoft's documentation plainly states (in the NT Version 4 DDK, "Kernel Mode Drivers", "Design Guide", section 1.2.1) that drivers should be written in ANSI C. However, the focus of this section is "Portability," and the main concern expressed in the text is that the driver be source-portable across processor architectures (x86 to Alpha). Microsoft has not (anywhere that I've found) described specific problems that have arisen from attempting to use C++ in drivers. As far as their own code is concerned, Microsoft appears to not be completely inflexible on this issue. GDI32 was originally written in C++ in user mode but was ported to kernel mode as of NT 4. Also, the NT5 (Win2K) Beta 2 DDK includes a sample audio streaming driver written in C++. A primary concern that has been widely expressed is that many of the C++ mechanisms need to generate some automatic storage that is not seen by (and therefore not under the control of) the programmer. Since kernel stack space is at a premium in kernel mode, this is a valid concern, but it is difficult to quantify. The extra "layer" of calls to virtual functions will obviously place extra call frames on the stack, and take extra time as well. At least two commercial products exist that provide C++ class libraries that "wrap" the NT KMD environment. It is safe to assume that if anyone had had problems with them, especially "showstopper" problems involving their use of C++, the fact would have been publicized and widely discusssed in the relevant newsgroups. No such problems have been reported in the over two years that these products have existed. I would argue that if you're going to use C++ it would be of great benefit to use one of the existing C++ support products. (See the Related Products page.) These vendors have already done the work to implement kernel mode-safe replacements for the C++ support RTL. My final argument against C++ is more practical than technical: Microsoft has in the past steered strictly away from it in kernel mode, and there are still far more kernel mode source modules, and especially driver source modules, of type `.c` than of type `.cpp` . Now MS does a complete build of NT from source (including all drivers) at least once a day, and many, many developers within MS build drivers many times each day. So, when it comes to code that will run in kernel mode, MS tests their new versions of the compiler far more thoroughly in "C mode" than in "C++ mode". So even if a driver compiles correctly under the current compiler, I have far less confidence as to what will happen under future compilers if the source is in C++. Of course I can't prove that there will be a problem with C++ code in kernel mode under a future compiler version. My issue is that if I stick to C, MS claims there won't be a problem, and they make no such claims for C++. I must confess that I'm one of those who frankly doesn't see a compelling advantage, either in portability or in code safety, for C++, so you should evaluate my "stick to C" opinion in that light. On the other hand, the C++ proponents have quite a vested interest (in terms of code shipped to customers) in their position. So, as a famous witness for the prosecution once said in a British court, when told that the defense denied all charges... "Well, they would say that, wouldn't they?" That should be kept in mind when reading their arguments. top of page \| up \| previous \| next \| home