i wud be curious to know what is the compelling reason of not using c++ in
windows kernel programming (apart from optimizations). y is it that even if
i use a c++ compiler to compile a driver, MS doesnt support it?
Hey! Be so kind and search archives. It was discussed many times in the past and this discussion always leads to a flamewar.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of A P[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, January 24, 2008 8:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] c++i wud be curious to know what is the compelling reason of not using c++ in windows kernel programming (apart from optimizations). y is it that even if i use a c++ compiler to compile a driver, MS doesnt support it?
ā NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks Dude for bring it up. Good Q?
-pro
On Jan 24, 2008 11:23 AM, A P wrote:
> i wud be curious to know what is the compelling reason of not using c++ in
> windows kernel programming (apart from optimizations). y is it that even if
> i use a c++ compiler to compile a driver, MS doesnt support it?
>
>
> ā NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
A P wrote:
i wud be curious to know what is the compelling reason of not using
c++ in windows kernel programming (apart from optimizations). y is it
that even if i use a c++ compiler to compile a driver, MS doesnt
support it?
This is not instant messaging; please use real words.
This restriction is not absolute. AVStream drivers, BDA drivers, and
some types of audio drivers have been in C++ for a rather long time,
even in the DDK samples.
ā
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Michal had it right, this is just provoking a religious flame war, it is a
lousy question. If you want to find out the opinions, look at the archives.
ā
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
āProkash Sinhaā wrote in message news:xxxxx@ntdevā¦
> Thanks Dude for bring it up. Good Q?
>
> -pro
>
>
>
>
> On Jan 24, 2008 11:23 AM, A P wrote:
>
>> i wud be curious to know what is the compelling reason of not using c++
>> in
>> windows kernel programming (apart from optimizations). y is it that even
>> if
>> i use a c++ compiler to compile a driver, MS doesnt support it?
>>
>>
>> ā NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
LOL 
A P has been around for quite some time and should know better !!!
-pro
Michal had it right, this is just provoking a religious flame war, it is a
lousy question. If you want to find out the opinions, look at the
archives.ā
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to replyāProkash Sinhaā wrote in message news:xxxxx@ntdevā¦
>> Thanks Dude for bring it up. Good Q?
>>
>> -pro
>>
>>
>>
>>
>> On Jan 24, 2008 11:23 AM, A P wrote:
>>
>>> i wud be curious to know what is the compelling reason of not using c++
>>> in
>>> windows kernel programming (apart from optimizations). y is it that
>>> even
>>> if
>>> i use a c++ compiler to compile a driver, MS doesnt support it?
>>>
>>>
>>> ā NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>> and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> ā
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Don,
Michal had it right, this is just provoking a religious flame war, it is a lousy question.
To be honest, when I saw posterās name, first I thought it was Alberto - after all, C vs C++ is one of his favorite topics. Actually, I donāt see anything wrong with starting a *separate* thread on this subject, i.e. do things the way OP does - no matter how you see it, you just cannot accuse him of of hijacking a thread. Instead, you are āwarnedā in advance what it is about, so that no one forces you to read it if you have no interest in this topicā¦
Anton Bassov
MS very well supports it, there are ways to do it with classic drivers and there have even been articles in the NT Insider and in the archive of this list. C++ mostly provides very good type checking. Furthermore you can use some aspects of OO programming, but some consider it a waste of precious resources. Also most of the basis needed to work with C++ and classes is non-existent and needs to be provided by you 
Judge for yourself, but āurā question wasnāt written very professional, eh? Therefore bringing up such a ātouchyā topic in such a way might cause a flamewar.
Unpacking his asbestos suite in preparation for replies ;),
Oliver
-------- Original-Nachricht --------
Datum: Fri, 25 Jan 2008 00:53:15 +0530
Von: āA Pā
> An: āWindows System Software Devs Interest Listā
> Betreff: [ntdev] c++
> i wud be curious to know what is the compelling reason of not using c++ in
> windows kernel programming (apart from optimizations). y is it that even
> if
> i use a c++ compiler to compile a driver, MS doesnt support it?
>
> ā
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
ā
---------------------------------------------------
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
hi Anton,
the problem is that many people on this list donāt want to see the same
arguments again and again. Of couse nobody must read the read. But what is
it worth then?
All this reminds me very much on the disccusions āobjective Cā vs. āC++ā 15
years ago in the NeXT developer world. There also the same arguments were
exchanged again and again ā¦
ā Reinhard
wrote in message news:xxxxx@ntdevā¦
> Don,
>
>>Michal had it right, this is just provoking a religious flame war, it is a
>>lousy question.
>
> To be honest, when I saw posterās name, first I thought it was Alberto -
> after all, C vs C++ is one of his favorite topics. Actually, I donāt see
> anything wrong with starting a separate thread on this subject, i.e. do
> things the way OP does - no matter how you see it, you just cannot accuse
> him of of hijacking a thread. Instead, you are āwarnedā in advance what it
> is about, so that no one forces you to read it if you have no interest in
> this topicā¦
>
> Anton Bassov
>
Reinhard,
the problem is that many people on this list donāt want to see the same
arguments again and again
Sure. This is why, in my opinion, it makes sense to isolate these arguments on some separate thread(s) that will be completely ignored by the vast majority of readersā¦
Of couse nobody must read the read. But what is it worth then?
Well, even if thread is of no interest to overwhelming majority of list readers (letās say 95%),
it is still of interest to the remaining 5% (because otherwise no one would post to it, in the first place, so that it would just die in itself). This NG has more than 50K subscribers, which, if we assume 95% vs 5% ratio, still gives us 2 500 potential readers. You donāt really want to deny them a chance to discuss a topic that is of interest to them, do you (please note that I am not among them - Iāve got no interest in C vs C++ topic whatsoever). If you do ā¦ then think again - if they have no chance to do it here, they will be just raising this issue on other threads, effectively hijacking them. Just to give you an idea, in the last 2 weeks I saw C vs C++ discussion on 3 threads that I have participated inā¦
Anton Bassov
lots have been already said and done with this thread. But on one gave the
ārealā answers. while it is true that the poster whud read older postings
before submitting, we shud appreciate tht electronic searches still depend
on search strings and might not always reveal thebest results. any how, i
simply googled, and here is a copy paste from what i foundā¦hope this
helpsā¦
C++ Issues for Kernel-Mode Drivers
Microsoft developers have discovered a number of areas where C++ presents
particular problems for kernel-mode drivers.
*Code in Memory*
The most severe problem with using C++ for writing kernel-mode drivers is
the management of memory pages, particularly code in memory, rather than
data. It is important that large drivers be pageable, and paged code is not
always in memory. All of the code that will be needed must be resident
before the system enters a state in which paging cannot occur.
The way the C++ compiler generates code for non-POD classes and templates
makes it particularly difficult to know where all the code required to
execute a function might go and thus difficult to make the code safely
pageable. The compiler automatically generates code for at least the
following objects. These objects are put āout of line,ā and the developer
has no direct control over the section in which they are inserted, which
means they could happen to be paged out when needed.
?
Compiler-generated code such as constructors, destructors, casts, and
assignment operators. (These can often be explicitly provided, but it
requires taking care to recognize that they need to be provided.)
?
Adjustor thunks, used to convert between various classes in a hierarchy.
?
Virtual function thunks, used to implement calls to virtual function.
?
Virtual function table thunks, used to manage base classes and polymorphism.
?
Template code bodies, which are emitted at first use unless explicitly
instantiated.
?
The virtual function tables themselves.
The C++ compiler does not provide mechanisms for direct control of where
these entities are placed in memory. The pragmas necessary to control memory
placement were not designed with C++ in mind. #pragma alloc_text cannot be
used to control the location of a member function because (for several
reasons) there is no way to name the member function. The scope of #pragma
code_seg is ambiguous for compiler-generated functions, expanded template
bodies, and compiler-generated thunks. There is no mechanism at all for
controlling the location of virtual function tables, since they are not
quite either code or data from the point of view of the compiler (they go
into a section all their own).
If a function in a header is declared inline, but the compiler does not
generate inline code for it, the function may be emitted in more than one
code segment depending on where the function is used. When a class template
is instantiated, it is generated in the section that is current at the point
of first use, and it is not always immediately obvious which section that
is. Both of these issues can lead to code being pageable when it should not
be, or vice versa.
If a class hierarchy is in use, whether code for a base class needs to be in
memory when the derived class is accessed depends on exactly which functions
in the base class are called from the derived class (and whether the
compiler can inline them), as well as what sections they were emitted in.
For example, if the derived class provides a method that uses no base class
methods, the base class code need not be in memory. However, it is difficult
to know when that is the case. Additionally, any thunks used with the
hierarchy and its classes might also need to be resident in memory.
*Stack*
The compiler has always been free to generate additional data on the stack,
such as creating temporary objects, deferring call cleanup, and other
actions that use the stack in a hidden fashion. There are few differences
between C and C++ with respect to the way a single function uses the stack,
but because of the additional mechanisms that usually result in more
function calls, C++ will often use more total stack. You should keep stack
size in mind, as you would in any programming language when stack space is
limited.
Exceptions also have an effect on the stack. See āExceptions and RTTIā later
in this paper.
*Dynamic Memory*
Driver development tools such as Driver Verifier rely on tagged memory to
validate memory usage in drivers. Using *operator new* and *operator
delete*to allocate and free memory weakens the ability of these tools
to detect
memory leaks and other problems in driver code.
In user space,* operator new* and *operator delete* are convenient, but they
can become cumbersome in drivers that use multiple memory pools or tagged
memory. Because āplacement newā takes additional operands, it is possible to
pass in the information needed to select memory pools or generate tags into
an overloaded *operator new* , but this is not much easier than using the
memory functions directly. Because there is no āplacement deleteā with
additional arguments to pass in a tag or a pooltype, there is no way to pass
in a tag (or memory control, if needed) when using *operatordelete*, making
it impossible to check that the tag at the point of release was the intended
one, thus defeating much of the benefit of using tagged memory. It is
possible to *delete* memory without providing a tag, but in each case you
will need to decide whether the risks and disadvantages of not using tags in
driver code overcome the apparent convenience.
Memory tracing tools often record the return address of the function that
made an allocation. Some C++ compilers implement *operator new* as a
function, causing all allocations to appear to come from a single location
and defeating the purpose of that aspect of the memory tracing tool. This
can be addressed, but you will have to determine for yourself if there is a
benefit in doing so over using memory allocation directly.
*Libraries*
There are a number of distinct concerns in creating and using libraries:
?
The name of exported C++ functions can vary from one release to another.
?
Not all of the functions available in user mode are available in the
kernel-mode libraries.
?
The Standard Template Library is designed to work with data objects from a
single DLL.
C++ functions are exported based on their entire signature, not on their
name alone (as C functions are). The name of a C++ function is āmangledā to
contain type information, which becomes part of its signature. Although the
rules for name mangling are fairly stable, there is no guarantee that the
mangled names will be the same from release to release of the compiler.
Therefore, C++ functions cannot be reliably exported to a library from one
release to the next, although functions that can be represented as *extern
āCā* functions can. In addition, the use of a .def file can help mitigate
the problem. Note that *extern āCā* functions are unique only on the basis
of name, not the entire signature as in C++.
Not all library functions are available in kernel mode, particularly those
associated with the āadvancedā C++ language features. The Standard Template
Library is the āusualā way to implement many C++ concepts such as variably
sized arrays. However, it is unsafe to simply assume that the Standard
Template Library is present and usable. Although much of the Standard
Template Library is implemented as source code in headers, it occasionally
uses library functions or other features that are not available or usable in
the kernel environment.
The Standard Template Library is also based on the assumption that each data
object it uses exists in only a single DLL. Although in most cases it works
to pass references to POD objects across DLL boundaries, passing references
to more complex structures such as lists may cause runtime failures that can
be hard to diagnose. Known issues include the fact that freeing memory in a
DLL other than the one in which the memory was allocated can cause failures
(at least for debug-mode compiles) and that the āend of listā marker differs
between DLLs, which can cause unexpected runaway list searches. You must be
aware of these problems and take steps to prevent them.
We do not recommend using Standard Template Library functions in a
kernel-mode driver, because it is not possible to assume that the Standard
Template Library is there and ājust works.ā In the case of kernel-mode code,
understanding precisely how a particular data structure is implemented helps
assure that it does not violate the requirements of kernel space. It is also
possible that a specialized implementation will be smaller than the more
general Standard Template Library functions, although the library is often
very good in that regard.
*Exceptions and RTTI*
It is tempting to use C++ exceptions, but they are difficult to implement in
kernel mode. C++ exceptions require a kernel-mode-safe library, which does
not currently exist. They also present an unavoidable runtime problem,
because exception records that are generated when an exception is thrown are
large objects on the very limited stack. On x86 systems, exception records
are not particularly large (although they are large compared with many
typical stack frames), but on Intel Itanium systems they are quite large: 3K
to 4K, or one-sixth to one-eighth of the available 24K stack space. To
preserve portability of a driver to 64-bit platforms, exceptions would have
to be used in a very limited way, even on the x86 architecture. The *rethrow
* operator can cause multiple exception records on the stack. Note that
Structured Exception Handling (*__try* /*__except*/*__finally*) is available
in kernel mode, although the space concerns remain. C++ exceptions have a
number of semantic subtleties that prevent them from simply mapping onto
Structured Exception Handling.
Run-time type information (RTTI) also requires a library that does not
currently exist for C++ in kernel mode. So far, there have been few, if any,
requests for this in kernel-mode code. Whether this lack of demand is a
consequence of the other problems masking it or because it is not useful in
kernel mode is unknown.
*Compiler Versions*
Although the C++ language standard is stable, implementation techniques are
still evolving. Consequently, compiler versions may change the way generated
code operates. Such changes are unlikely to affect user-mode code, but they
can affect kernel-mode code in which more of the underlying implementation
is exposed to (and sometimes provided by) driver developers;
version-to-version interoperability of kernel-mode code is not guaranteed.
You should carefully control any interface between two drivers or a driver
and the operating system, usually by writing the interface in C instead of
C++. Otherwise, version-to-version incompatibilities in the C++
implementation may cause interoperability failures.
*Static and Global Scope Variables and Initialization*
C++ static variables (declared at either global or local scope) present a
number of problems for drivers.
The C++ standard allows *static* variables declared at local scope to be
initialized at the time of first use (the first time the scope is entered).
The way this is implemented both creates the possibility of race conditions
during initialization and a particularly high risk of unintended data
sharing between threads, because variables declared *static* are globally
static, not per-thread. For globally static data (shared among threads) it
is best to do it explicitly at global scope, to make sure access protections
appropriate to the situation are applied.
If a C++ global object requires initialization (a global constructor) is
declared, there is no mechanism for the constructor to be called. Global
objects that require constructors should either not be used, or you must
develop a mechanism to assure that the constructor is called. Several
sources on the Web claim to have solved this problem, and one of those
solutions might work for you.
The order of initialization of global objects is not specified by the C++
standard, so even if there were a mechanism to call their constructors,
either the order of initialization must be explicitly controlled by the
driver code, or it must not matter.
On Jan 25, 2008 3:12 PM, wrote:
> Reinhard,
>
> > the problem is that many people on this list donāt want to see the same
> > arguments again and again
>
> Sure. This is why, in my opinion, it makes sense to isolate these
> arguments on some separate thread(s) that will be completely ignored by the
> vast majority of readersā¦
>
> > Of couse nobody must read the read. But what is it worth then?
>
> Well, even if thread is of no interest to overwhelming majority of list
> readers (letās say 95%),
> it is still of interest to the remaining 5% (because otherwise no one
> would post to it, in the first place, so that it would just die in itself).
> This NG has more than 50K subscribers, which, if we assume 95% vs 5% ratio,
> still gives us 2 500 potential readers. You donāt really want to deny them
> a chance to discuss a topic that is of interest to them, do you (please
> note that I am not among them - Iāve got no interest in C vs C++ topic
> whatsoever). If you do ā¦ then think again - if they have no chance to
> do it here, they will be just raising this issue on other threads,
> effectively hijacking them. Just to give you an idea, in the last 2 weeks I
> saw C vs C++ discussion on 3 threads that I have participated inā¦
>
> Anton Bassov
>
> ā
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
ā
- amitr0
Sorry, but what does all the above have to do with C vs C++???
All above mentioned things are specific to MSFT compilers. Therefore, it is not about concepts but about particular implementations of these conceptsā¦
Anton Bassov.
The OP asked about C++ for Windows drivers, since the only compiler that
supports Windows drivers is Microsoft the comments are valid. It should
also be pointed out that since Microsoft C compiler does C++ level type
checking if you use /W4 the strongest argument for C++ is invalid in the
kernel environment.
ā
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdevā¦
> Sorry, but what does all the above have to do with C vs C++???
>
> All above mentioned things are specific to MSFT compilers. Therefore, it
> is not about concepts but about particular implementations of these
> conceptsā¦
>
> Anton Bassov.
>
> The OP asked about C++ for Windows drivers, since the only compiler
that supports Windows drivers is Microsoft the comments are valid.
Actually, according to Peter, GNU compiler can generate a Windows driver as well, although it would require quite a few modifications to headers. Any any case, building Windows drivers with anything, apart from WDK, is really stupid - this is one of the issues on which we both agreeā¦
Anton Bassov
> The OP asked about C++ for Windows drivers, since the only compiler that
supports Windows drivers is Microsoft the comments are valid. It should
also be pointed out that since Microsoft C compiler does C++ level type
checking if you use /W4 the strongest argument for C++ is invalid in the
kernel environment.
Don,
I beg to differ. There are a lot of other advantages of C++ over C (unless we talk C99, which somewhat decreases the number). Just to name a few:
- Declaring variables anywhere in the scope, i.e. directly before use (also in C99)
- Using references instead of pointers to give the compiler some clue as to what we mean (e.g. if NULL pointers would be invalid)
- if(type name = bla()) {} (I believe this was possible in C99 as well)
- templated functions and types in order to perform some pretty useful āmagicā that ensure type checking where otherwise some ugly casts would be used in C(99)
- Variadic preprocessor macros (also in C99)
- Typecast operators
- Overloading of operators for <, > +, ++, --, ==, != (etc pp).
There are surely more points, but those are the ones I consider important for myself. Also, I agree that due to the high warning level you gain additional type security (apparently not identical, though), but with the above considerations, there should be still a number of advantages even if we leave out āclassesā.
So while I am not completely opposed to use of classes in KM, I am sceptical of many aspects, but want to use the other advantages (of C++) in any case.
// Oliver
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
Iāve heard Microsoft has no plans to provide C99 compiance in the compiler. Can anyone speak to this? Thanks.
Oliver,
We are now back to intangibles. The early articles on C++ in the
kernel used the poweful argument of better type checking, and that argument
is no longer valid. Whether the things you list are good or bad are style
issues not arguments that can be made for the case of improving drivers.
We all have our own style, much of what you list I will not use. In
fact some of those items below are things I know of a number of very heavy
C++ shops which disallow their use.
ā
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
āOliver Schneiderā wrote in message
news:xxxxx@ntdevā¦
>> The OP asked about C++ for Windows drivers, since the only compiler that
>> supports Windows drivers is Microsoft the comments are valid. It should
>> also be pointed out that since Microsoft C compiler does C++ level type
>> checking if you use /W4 the strongest argument for C++ is invalid in the
>> kernel environment.
>
> Don,
>
> I beg to differ. There are a lot of other advantages of C++ over C (unless
> we talk C99, which somewhat decreases the number). Just to name a few:
>
> - Declaring variables anywhere in the scope, i.e. directly before use
> (also in C99)
> - Using references instead of pointers to give the compiler some clue as
> to what we mean (e.g. if NULL pointers would be invalid)
> - if(type name = bla()) {} (I believe this was possible in C99 as well)
> - templated functions and types in order to perform some pretty useful
> āmagicā that ensure type checking where otherwise some ugly casts would be
> used in C(99)
> - Variadic preprocessor macros (also in C99)
> - Typecast operators
> - Overloading of operators for <, > +, ++, --, ==, != (etc pp).
>
> There are surely more points, but those are the ones I consider important
> for myself. Also, I agree that due to the high warning level you gain
> additional type security (apparently not identical, though), but with the
> above considerations, there should be still a number of advantages even if
> we leave out āclassesā.
>
> So while I am not completely opposed to use of classes in KM, I am
> sceptical of many aspects, but want to use the other advantages (of C++)
> in any case.
>
>
> // Oliver
> ā
> ---------------------------------------------------
> May the source be with you, stranger
>
> ICQ: #281645
> URL: http://assarbad.info | http://windirstat.info |
> http://blog.assarbad.info
>
>
Oliver Schneider wrote:
I beg to differ. There are a lot of other advantages of C++ over C (unless we talk C99, which somewhat decreases the number). Just to name a few:
- Declaring variables anywhere in the scope, i.e. directly before use (also in C99)
To me, this is a big deal.
- Using references instead of pointers to give the compiler some clue as to what we mean (e.g. if NULL pointers would be invalid)
- if(type name = bla()) {} (I believe this was possible in C99 as well)
You mean typeid(xxx).name()? I didnāt think that was present in C99. I
have to admit Iāve never used it, because of the perceived performance
hit that RTTI implies.
- templated functions and types in order to perform some pretty useful āmagicā that ensure type checking where otherwise some ugly casts would be used in C(99)
- Variadic preprocessor macros (also in C99)
Variadic macros are ONLY in C99. They are not part of standard C++ (yet).
- Typecast operators
- Overloading of operators for <, > +, ++, --, ==, != (etc pp).
Many people think that operator overloading is a DISADVANTAGE of C++.
Itās clear that there are many places where it is useful (strings,
complex numbers, rational numbers), but they are just way too easy to
abuseā¦
There are surely more points, but those are the ones I consider important for myself. Also, I agree that due to the high warning level you gain additional type security (apparently not identical, though), but with the above considerations, there should be still a number of advantages even if we leave out āclassesā.
So while I am not completely opposed to use of classes in KM, I am sceptical of many aspects, but want to use the other advantages (of C++) in any case.
Classes are just structs with function pointers. I donāt see why that
would be an issue.
ā
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
> - Variadic preprocessor macros (also in C99)
Variadic macros are ONLY in C99. They are not part of standard
C++ (yet).
Variadic macros are actually supported by the 6000 WDK.
Many people think that operator overloading is a DISADVANTAGE
of C++.
(strings, complex numbers, rational numbers), but they are just
way too easy to abuseā¦
boost::format uses the % operator to implement a var-args of sorts with their printf implementation
i.e. cout << boost::format(ā%2% %1%ā) % 36 % 77)
You lost me on your first āadvantageā. Why donāt we just make variables
that start with i through m integers, and then you wonāt have to bother
declaring anything.
Declaring the variable at first use instead of at the top of the function
just makes for ugly, unreadable code.
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Oliver Schneider
Sent: Friday, January 25, 2008 12:29 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] c++
The OP asked about C++ for Windows drivers, since the only compiler
that supports Windows drivers is Microsoft the comments are valid. It
should also be pointed out that since Microsoft C compiler does C++
level type checking if you use /W4 the strongest argument for C++ is
invalid in the kernel environment.
Don,
I beg to differ. There are a lot of other advantages of C++ over C (unless
we talk C99, which somewhat decreases the number). Just to name a few:
- Declaring variables anywhere in the scope, i.e. directly before use (also
in C99) - Using references instead of pointers to give the compiler some clue as to
what we mean (e.g. if NULL pointers would be invalid) - if(type name = bla()) {} (I believe this was possible in C99 as well)
- templated functions and types in order to perform some pretty useful
āmagicā that ensure type checking where otherwise some ugly casts would be
used in C(99) - Variadic preprocessor macros (also in C99)
- Typecast operators
- Overloading of operators for <, > +, ++, --, ==, != (etc pp).
There are surely more points, but those are the ones I consider important
for myself. Also, I agree that due to the high warning level you gain
additional type security (apparently not identical, though), but with the
above considerations, there should be still a number of advantages even if
we leave out āclassesā.
So while I am not completely opposed to use of classes in KM, I am sceptical
of many aspects, but want to use the other advantages (of C++) in any case.
// Oliver
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info |
http://blog.assarbad.info
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer