Jump-start your project by learning from devs who
write Windows drivers and file systems every day.
Take an OSR seminar!

Upcoming OSR Seminars:
WDM Lab, Seattle, WA 16 August 2010
WDF Lab, Santa Clara, CA 27 September 2010
Debug Lab, Portland, OR 18 October 2010
Windows Internals & Software Drivers Lab, Santa Clara, CA 15 November 2010


Go Back   OSR Online Lists > ntdev
link c++
Welcome, Guest
You must login to post to this list
  Message 1 of 108  
24 Jan 08 14:24
Albert
xxxxxx@gmail.com
Join Date: 08 Aug 2005
Posts To This List: 232
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? --
  Message 2 of 108  
24 Jan 08 14:31
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1602
RE: c++
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? > > <...excess quoted lines suppressed...>
  Message 3 of 108  
24 Jan 08 14:32
ntdev member 32707
xxxxxx@gmail.com
Join Date:
Posts To This List: 141
Re: c++
Thanks Dude for bring it up. Good Q? -pro On Jan 24, 2008 11:23 AM, A P <xxxxx@gmail.com> 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 --
  Message 4 of 108  
24 Jan 08 14:51
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 5070
Re: c++
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.
  Message 5 of 108  
24 Jan 08 15:09
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: c++
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" <xxxxx@gmail.com> wrote in message news:101042@ntdev... > Thanks Dude for bring it up. Good Q? > > -pro > > > > > On Jan 24, 2008 11:23 AM, A P <xxxxx@gmail.com> wrote: > >> i wud be curious to know what is the compelling reason of not using c++ <...excess quoted lines suppressed...>
  Message 6 of 108  
24 Jan 08 15:31
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 760
Re:c++
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 <...excess quoted lines suppressed...>
  Message 7 of 108  
24 Jan 08 16:51
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
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
  Message 8 of 108  
24 Jan 08 17:33
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: c++
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" <xxxxx@gmail.com> > An: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> > 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? > > --- <...excess quoted lines suppressed...> -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 9 of 108  
25 Jan 08 03:22
ntdev member 2587
xxxxxx@ixos.de
Join Date:
Posts To This List: 21
Re: c++
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 <xxxxx@hotmail.com> wrote in message news:101050@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 <...excess quoted lines suppressed...>
  Message 10 of 108  
25 Jan 08 04:41
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
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
  Message 11 of 108  
25 Jan 08 04:53
amitr0
xxxxxx@gmail.com
Join Date: 03 Aug 2005
Posts To This List: 364
Re: c++
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 Hand
  Message 12 of 108  
25 Jan 08 08:05
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
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.
  Message 13 of 108  
25 Jan 08 08:23
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: 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 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 <xxxxx@hotmail.com> wrote in message news:101082@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. >
  Message 14 of 108  
25 Jan 08 08:28
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> 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
  Message 15 of 108  
25 Jan 08 14:29
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: Re: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
  Message 16 of 108  
25 Jan 08 14:45
matt davison
xxxxxx@direct-logic.com
Join Date: 03 Jan 2008
Posts To This List: 17
RE: c++
I've heard Microsoft has no plans to provide C99 compiance in the compiler. Can anyone speak to this? Thanks.
  Message 17 of 108  
25 Jan 08 14:47
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: Re:c++
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" <xxxxx@gmxpro.net> wrote in message news:101094@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: <...excess quoted lines suppressed...>
  Message 18 of 108  
25 Jan 08 14:55
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 5070
Re: c++
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.
  Message 19 of 108  
25 Jan 08 15:03
Chris Aseltine
xxxxxx@gmail.com
Join Date: 23 Sep 2006
Posts To This List: 916
RE: c++
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++. ;) 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... 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)
  Message 20 of 108  
25 Jan 08 15:06
Dan Kyler
xxxxxx@privtek.com
Join Date: 23 Jan 2004
Posts To This List: 165
RE: Re:c++
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
  Message 21 of 108  
25 Jan 08 15:16
matt davison
xxxxxx@direct-logic.com
Join Date: 03 Jan 2008
Posts To This List: 17
RE: c++
>>Declaring the variable at first use instead of at the top of the function >>just makes for ugly, unreadable code. >> >>-Dan. I couldn't disagree more. Declaring the variable where it is used makes the code more modular and clean. Why have variables declared at the top if you don't even know if they are needed in some code paths. Sure you can introduce new scope and declare them there but requiring there declaration first does not help readability in the least. I don't get your argument.
  Message 22 of 108  
25 Jan 08 15:28
Scott Noone
xxxxxx@osr.com
Join Date:
Posts To This List: 557
List Moderator
Re: c++
I'm impressed. In an attempt to avoid arguing C vs C++ this thread has managed to become about where your variables should go. I suggest cutting this off right now and arguing something more important. To start us off, here are some suggestions I have: 1) Top posting vs bottom posting 2) Kirk vs.Picard 3) Alliance vs Horde 4) American Idol Season 1 or Season 2? Screw nttalk, maybe we need #ntdev... -scott Scott Noone Software Engineer OSR Open Systems Resources, Inc. http://www.osronline.com
  Message 23 of 108  
25 Jan 08 15:30
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: c++
Tim, > > - Declaring variables anywhere in the scope, i.e. directly before use > (also in C99) > > > > To me, this is a big deal. Don't know whether this was sarcasm, but to me it is a very cool feature. > 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. No, I meant more that you could do (with "sample" substitutions) do: if(ULONG x = MyFunc()) {} ... > Variadic macros are ONLY in C99. They are not part of standard C++ (yet). True, but modern C++ compilers implement the C99 subset, as far as I am aware. No?! > 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... Also true. You have to be strict in your own style, but then you can greatly enhance the readability and maintainability. > Classes are just structs with function pointers. I don't see why that > would be an issue. Also true. Ctors for structs/classes are a nice feature, too. I just wanted to show that there are advantages beyond the use of classes. // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 24 of 108  
25 Jan 08 15:41
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: RE: Re:c++
> Declaring the variable at first use instead of at the top of the function > just makes for ugly, unreadable code. Dan, reading the comments of Matt before replying to you, I agree with him. It makes it more modular! I've also seen people writing C code where the initialization of the variable was postponed and then the variable was used without being initialized. This was due to copying of code pieces from below to a location above (before the initialization == first use). In such a case declaring the variable before use would break the compile(! ... not just logic and therefore lead to a bug) since the variable wouldn't be declared in such a way that the whole scope is able to use it. This can be quite effective as an error-preventing style convention. // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 25 of 108  
25 Jan 08 15:47
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: Re:Re:c++
Don, > Whether the things you list are good or bad are style > issues not arguments that can be made for the case of improving drivers. If they prevent mistakes (and consequently bugs) I consider that not just style in the cosmetic sense, though. > 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. Well, I know a lot of people who say they write C++, but if you look at there code it's just C++'s C-subset typed into a .cpp file, or even worse, some mix of classes with the disadvantages of C (by typing the C-code into member functions and declaring that a class). Overall I agree, though. This *is* and *remains* largely a matter of taste. And I hope I haven't offended anyone with my arguments so far. I was merely trying to state facts that I've found to be valid for me. // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 26 of 108  
25 Jan 08 16:10
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: Re:c++
Scott, > I'm impressed. In an attempt to avoid arguing C vs C++ this thread has > managed to become about where your variables should go. why the sarcasm? This is a proven way of avoiding errors in code and in case of the use of ctors it will even spare you the actual construction of the object, although it will admittedly not spare you the space on the function's stack frame. Also I haven't avoided the discussion, but rather stated this particular feature as one of the (legit, as I find) reasons to use the C++ compile mode rather than C without even touching the topic of classes (up to that point). I think it should be allowed to discuss the pros and cons (and also discuss them more than once during the lifetime of this list). I've seen all kinds of discussions cooking up every now and then - and repeatedly. Why is C vs. C++ such a touchy topic for many list members? And why is it "C *versus* C++" in the first place? As if there is only either one and a combination of both impossible. My SOURCES files gladly take a mixed list of .c and .cpp source files. Is my system messed up? :-) So far I've only read arguments against the use of *classes* (stack use, wasting nonpaged pool memory etc), but I haven't really seen any argument that explains why *not* to use some of the other features that C++ offers. Surely you don't only use the subset of C that was available in the very first C versions. Even when using "plain C" you surely use what came about during the evolution of this language. Don't you? > 1) Top posting vs bottom posting Appending the basic style guide (if there is any) to the "---\nNTDEV is sponsored by OSR" at the bottom may help to avoid further confusion as to what the preferences of OSR are in that case ;) ... if feasible, that is. ... and could we add "quoting of the whole mail vs. quoting of relevant parts"? ;) // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 27 of 108  
25 Jan 08 16:54
Scott Noone
xxxxxx@osr.com
Join Date:
Posts To This List: 557
List Moderator
Re: Re:c++
> why the sarcasm? Spend more time in the Northeast :) > Why is C vs. C++ such a touchy topic for many list members? I'm sure it wasn't the first time it came up. > ...you surely use what came about during the evolution of this language. > Don't you? Of course. And of course I have preferences as to which features to use and not use. I even have a preference as to where my variables should be declared (at the beginning, where god intended them to be), but I feel absolutely zero need to try to convert others seeing as how it *is* a preference. And I don't think people would have a problem with a discussion regarding the fitness of a particular language feature for a driver design. That would probably be a useful discussion that we all might learn something new from. However, these discussions are never that precise and helpful and typically devolve rather quickly into bandwidth wasting discussions of coding style. -scott -- Scott Noone Software Engineer OSR Open Systems Resources, Inc. http://www.osronline.com "Oliver Schneider" <xxxxx@gmxpro.net> wrote in message news:101110@ntdev... > Scott, > >> I'm impressed. In an attempt to avoid arguing C vs C++ this thread has >> managed to become about where your variables should go. > why the sarcasm? This is a proven way of avoiding errors in code and in > case of the use of ctors it will even spare you the actual construction of > the object, although it will admittedly not spare you the space on the > function's stack frame. > > Also I haven't avoided the discussion, but rather stated this particular <...excess quoted lines suppressed...>
  Message 28 of 108  
25 Jan 08 17:16
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 2663
Re: Re:c++
I post wherever my mail program is most comfortable posting, having learned that trying to force such apps to do other than they want to naturally do is just asking for a fight. Plus the lyris program seems to get odd sometimes. So the now ubiquitous gmail is a top poster... On Jan 25, 2008 4:09 PM, Oliver Schneider <xxxxx@gmxpro.net> wrote: > > > 1) Top posting vs bottom posting > Appending the basic style guide (if there is any) to the "---\nNTDEV is > sponsored by OSR" at the bottom may help to avoid further confusion as to > what the preferences of OSR are in that case ;) ... if feasible, that is. > > ... and could we add "quoting of the whole mail vs. quoting of relevant > parts"? ;) > > <...excess quoted lines suppressed...> But my sig gets to the bottom of the pile, making it sort of bracket posting. p.s. this may be the most profoundly offtopic hijacking this year! -- Mark Roddy --
  Message 29 of 108  
25 Jan 08 17:44
Ray Trent
xxxxxx@synaptics.spamblock.com
Join Date: 25 Aug 2003
Posts To This List: 392
Re: c++
Oliver Schneider wrote: > So far I've only read arguments against the use of *classes* (stack use, wasting nonpaged pool memory etc) Since we're restarting this old flamewar anyway... :-). I will argue that classes are the *very best reason* to use C++ in the kernel. The modularization advantages of object oriented programming, while theoretically possible to achieve with C using structs and careful programming, are vastly easier with a language that was designed to handle them. Can you abuse C++? Easily. Don't abuse the language and it won't abuse you. Inheritance, even multiple inheritance sometimes, is a useful tool for maintainability and cross-platform portability. Done well, with proper respect and restraint, it's like having your own specialized platform-independent driver model to program to. I'd say 10% or fewer of our files contain anything even *Windows* specific, much less 9x/NT/2k/XP/Vista specific. We had a working port of our driver to KMDF in a day or two (admittedly, a trivial port that just escaped out to manual IOCTL handling at first... a real port took a while longer, but we could do it one step at a time and have a working testable driver the whole way). The supposed problem of non-paged pool usage got silly years ago. Anyone still worrying about the non-paged pool usage of their kernel-mode driver today is writing *way* too much code to put in the kernel. The only people that maybe should worry about that are Microsoft, and even there I'm dubious. Certainly any advantage I could gain in my drivers by making some bits pageable would be relatively tiny... the vast majority of it is device logic that needs to be able to run at DPC level anyway. And never changing the code segment means you simply don't have to worry about where the compiler puts default constructors, template instantiations, etc. Stack space with C++ is only a problem if you use C++ exceptions or RTTI, really, and that would be truly foolish in the kernel for a vast number of reasons, assuming they're not just foolish everywhere :-). Indeed, I save stack space by judicious use of member variables far more often than I lose it. Similarly, every virtual function you call saves a ton of stack space over a similarly portable and modular C 2-level call hierarchy with switches for different object types, and is a gazillion times more maintainable. However, your mileage may vary if you're in a really deep driver stack. The other stuff is fluff. Declarations near use? Whatever. Keep your functions small enough (as you should be doing anyway) and you won't have problems with putting your declarations at the top. At best it's a very slight readability advantage, undone entirely if you actually overload operators (ugh... but in the old days syntactic sugar seemed sweeter than it does now). If you're making use of dynamic_casts, you're abusing the language (and are probably hampered by not having RTTI available anyway). More fluff. There might be a 1% exception to that declaration, but I'll stand behind it in the kernel. There is one big type-safeness advantage you get from C++ than C can't (easily) reproduce: templatized collections. People argue that templates aren't safe, but I've been using them for 10+ years in the kernel, and never once had a problem related to them. In fact, they've only prevented problems for me. Don't abuse templates and they won't abuse you. And no metaprogramming in a kernel driver! :-). Oh, that and RAII-style locks. *Damn* those are useful. They keep you out of more trouble than almost anything else in C++. Never having to worry about releasing a lock on some rare error case code-path lets me sleep so much better at night. If you're just a little bit clever, you can use them to enforce lock hierarchies as well. Anyway, I could go on, but don't let people tell you that C++ contains only marginal advantages, or redirect the conversation to fluff like declaration placement... focusing on the fluff is just a way to derail the conversation into a direction where C probably really is better. -- Ray (If you want to reply to me off list, please remove "spamblock." from my email address)
  Message 30 of 108  
25 Jan 08 18:31
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> Classes are just structs with function pointers Actually, the only difference between class and struct in C++ is that the former ones all members are private by default. In all other respects they are exactly the same thing. It just somehow happened that structures are usually declared only with data members, apparently, due to their C heritage. However, this is just a public perception, rather than language feature - if you want to declare a structure with virtual functions and multiple inheritance, the compiler is not going to stand in your way.... Anton Bassov
  Message 31 of 108  
25 Jan 08 20:21
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: Re:c++
Ray, Mark, Scott, (Ray wrote:) > Oh, that and RAII-style locks. *Damn* those are useful. They keep you > out of more trouble than almost anything else in C++. ... RAII, goes very well together with declaring a variable where it's needed (and not earlier) ;-) > Anyway, I could go on, but don't let people tell you that C++ contains > only marginal advantages, or redirect the conversation to fluff like > declaration placement... focusing on the fluff is just a way to derail > the conversation into a direction where C probably really is better. I don't, but since it appeared/appears that the majority of the frequent posters on NTDEV were/are opposed to C++ classes in KM, I thought I should show that there is a lot more besides the obvious. The fact that the positioning of the variables has been ridiculed like this only leaves me puzzled. If I recall correctly I posted more than just this one point. (Mark wrote:) > But my sig gets to the bottom of the pile, making it sort of bracket > posting. > p.s. this may be the most profoundly offtopic hijacking this year! And it's only January ;o) (Scott wrote:) > Spend more time in the Northeast :) Northeast ... of? The dark winter in Iceland can be quite depressing, so I can also be sarcastic during this time :) > Of course. And of course I have preferences as to which features to use > and not use. I even have a preference as to where my variables should be > declared (at the beginning, where god intended them to be), but I feel > absolutely zero need to try to convert others seeing as how it *is* a > preference. Nor do I. That's why I wrote that these are my *personal* favorites of the C++ features that I do not want to miss, even in KM. I thought I had made that part clear. > And I don't think people would have a problem with a discussion > regarding the fitness of a particular language feature for a driver > design. That would probably be a useful discussion that we all might > learn something new from. In hindsight you are completely right. The question was too general to be discussed without the hot temper that usually goes with "C vs. C++" on NTDEV. But at least some opinions and points have been exchanged, so I suppose it was useful for some of us ;) Have a nice weekend everyone! // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 32 of 108  
26 Jan 08 01:31
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: Re:c++
> - Using references instead of pointers to give the compiler some clue as to what >we mean (e.g. if NULL pointers would be invalid) C++ references are just plain evil. The whole idea of having 2 sets of the same features in a language, one being fully implemented (pointers) and one being a pathetic klugde (references - they are not objects, there are no arrays of references and they also have major issues with autocast in the inheritance tree) - is bad. From what I understand, the only real value of references is to implement lvalue parameters and lvalue return values for things like operator++() or operator[](). In any other context, using a pointer to implement lvalue parameter is better. Most C++ code (except operator[]() and such) only benefits if you replace all references with pointers. In reality, the bug with passing a NULL pointer somewhere is the most uncommon bug ever met :-) > - if(type name = bla()) {} (I believe this was possible in C99 as well) RTTI is trivially implementable by macros and inheritance, so, I do not think there is any value of having it in language. > - Typecast operators > - Overloading of operators for <, > +, ++, --, ==, != (etc pp). Also should be used with care, since they reduce the code readability. If you have "a = b;", it is a bit hard for a reader to scan all header files and find that this is actually "a = b.operator A();". >should be still a number of advantages even if we leave out "classes". Classes themselves are actually one of the best features of C++. The language is mainly used for classes and templates, and not for references and operator T. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 33 of 108  
26 Jan 08 01:48
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> Can you abuse C++? Easily. Don't abuse the language and it won't abuse > you. Inheritance, even multiple inheritance sometimes, is a useful tool > for maintainability and cross-platform portability. Correct. Now note lots of unexperienced C++ coders, who know the language features (including the most recent ones of 2000ies), but have no intuitive sense of how to do things easily. What they do is overuse of all language features, with a (IMHO perverted) view of "using the smart - and especially recent - features is The Good by itself, and is much more imporant than code readability and simplicity". This leads to ~5 times more code to implement the same, and to wrong choice of language features to implement the task (like trying to do polymorphic object loading from a stream using references instead of pointers - switching to pointers is 10 times easier then doing this with references which have issues with autocast in the inheritance tree). All of the above is not related to Windows kernel-mode development. It is a general thing. And yes, this is the basis of all anti-C++ positions - by some of us here, by Linus Torvalds etc. > If you're making use of dynamic_casts, you're abusing the language (and > are probably hampered by not having RTTI available anyway). Correct. In early C++ days, Stroustrup (with Ellis) provided a perfectly valid reason of why _he does not want any RTTI features to be in the language_: a) they provocate non-polymorphic coding styles b) hardcoding the layout of the "class object" to the compiler is evil. > There is one big type-safeness advantage you get from C++ than C can't > (easily) reproduce: templatized collections. Templates are good, one of the best features of C++, though metaprogramming has hardly any value in it except being an ivory tower adornment :-) -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 34 of 108  
26 Jan 08 01:50
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: Re:c++
> ... RAII, goes very well together with declaring a variable where it's needed (and ? >not earlier) ;-) For RAII code to be readable, your should declare only after {, so that {} will be the locked code path. Otherwise, the code reader will be confused a lot on what is the locked code path. >C++ classes in KM Not classes, but other things in C++. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 35 of 108  
26 Jan 08 01:52
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> > Classes are just structs with function pointers > > Actually, the only difference between class and struct in C++ is that the former >ones all members are private by default. Correct, but class/struct in C++ is wider then struct in C - member functions, language-supported vtables, inheritance, construction/deconstruction, ability to customize passing by value and to overload the operators. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 36 of 108  
26 Jan 08 01:53
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: Re:Re:c++
> Well, I know a lot of people who say they write C++, but if you look at there code >it's just C++'s C-subset typed into a .cpp file, or even worse, some mix of classes >with the disadvantages of C (by typing the C-code into member functions and >declaring that a class). This is probably the best way of C++ use. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 37 of 108  
26 Jan 08 02:23
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
>....member functions, language-supported vtables, inheritance, construction/deconstruction, > ability to customize passing by value and to overload the operators. So there is only one question left - do we really need all the above (and quite a few features beyond that) in the kernel mode??? Anton Bassov
  Message 38 of 108  
26 Jan 08 07:19
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
I would completely agree with your assessment of "using the smart...," and add that the situation is a party compared to what people who learned C# first do, like have fifteen different singlets in one program, and look at you like you are some out of your mind dinosaur if you don't do the same. > Templates are good, one of the best features of C++, though metaprogramming has > hardly any value in it except being an ivory tower adornment :-) You're being far, far too kind here. Metaprogramming is the one of the silliest things I can think as far as programming goes, with the notable exception of 'Extreme Programming;' however I would say templates are easily C++'s best feature. mm Maxim S. Shatskih wrote: >> Can you abuse C++? Easily. Don't abuse the language and it won't abuse >> you. Inheritance, even multiple inheritance sometimes, is a useful tool >> for maintainability and cross-platform portability. > > Correct. Now note lots of unexperienced C++ coders, who know the language > features (including the most recent ones of 2000ies), but have no intuitive > sense of how to do things easily. > > What they do is overuse of all language features, with a (IMHO perverted) view > of "using the smart - and especially recent - features is The Good by itself, <...excess quoted lines suppressed...>
  Message 39 of 108  
26 Jan 08 07:46
Oliver Schneider
xxxxxx@gmxpro.net
Join Date: 26 Jan 2004
Posts To This List: 170
Re: RE:c++
Anton, Maxim, (Anton wrote:) > So there is only one question left - do we really need all the above (and > quite a few features beyond that) in the kernel mode??? wrong question, IMO. The question more is whether *you* or *me* or anyone else him/herself or in team needs these features or finds them useful. It seems that the opponents of C++ in KM are quicker to tell *everyone* how to do what (i.e. not use C++), than the proponents are ;) (Maxim wrote:) > For RAII code to be readable, your should declare only after {, so that > {} will be the locked code path. Otherwise, the code reader will be > confused a lot on what is the locked code path. Sure. > Correct. Now note lots of unexperienced C++ coders, who know the language > features (including the most recent ones of 2000ies), but have no > intuitive sense of how to do things easily. Then educate them, if it's in your company. > In reality, the bug with passing a NULL pointer somewhere is the most > uncommon bug ever met :-) So? Uncommon doesn't mean it can't happen. And making the programmer go through hoops to make it happen, will at least get the programmer thinking (hopefully!), since it should then dawn them that this was *not* intended. No question, references are more restrictive than pointers, but *that's* the feature, otherwise it would be merely the clone of the functionality of pointers. References allow you to express requirements in code and the compiler will complain if the caller doesn't comply. I thought there was a broad consensus among programmers that forcing compiler errors, where the alternative would be runtime errors (which need handling and "~5 times more code to implement" ;) ...) was a good thing. Seems I was wrong. People use SAL to help PREfast understand the code. Use a few (or more) well-chosen C++ features and you'll help the *compiler* to understand your code (and intentions). > This leads to ~5 times more code to implement the same, and to wrong > choice of language features to implement the task (like trying to do > polymorphic object loading from a stream using references instead of > pointers - switching to pointers is 10 times easier then doing this with > references which have issues with autocast in the inheritance tree). I had something else in mind, e.g. the typical: if(void* x = malloc(12345)) { if(void* y = malloc(23456)) { // do some things ... if(SomeWeirdError()) { HandleError(); free(y); free(x); return -1; } // do some other things here free(y); } free(x); } You can make the code more modular and readable by using RAII here with the feature that classes on stack are destroyed when going out of scope *alone*. And if the original code with malloc/free (which is the kind of C I usally encounter in .cpp files of the aforementioned kind of people) "is probably the best way of C++ use", well then I am out of the discussion. It doesn't make sense to argue further then, because we have fundamentally different opinions on how to use/write C++. As was stated before by others, if you don't abuse C++, it won't abuse you! // Oliver -- --------------------------------------------------- May the source be with you, stranger ;) ICQ: #281645 URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
  Message 40 of 108  
26 Jan 08 08:41
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
I use C++ in a pretty full sense in the kernel every day, and I completely agree with your fundamental point - don't abuse it and it won't abuse you - as well as that the opponents are certainly more vociferous and, in my opinion, tend to be given to worst case scenarios that may or may not exist, and in some cases just hysteria, but I can't say that I agree with you in some places here. Fundamentally, I am much more interested in helping people understand the intent of source code than the compiler; the compiler is on it's own. In my opinion, I think Maxim's point here is that the NULL error is damn rare, and that some of the issues with the semantics of references are more common, which I would agree with, if that is in fact what he is saying. I don't use references much myself, except in the case of overloaded operators, which I don't use much either and are for all practical purposes unusable with out them, because they do not declare the intent or lack there of to modify an argument, whereas a pointer states that this is the working assumption, one which is not going to be true a lot of the time, but I prefer that problem than the one with references. It's not like either is a big deal, but over time, '->' has been etched in to my brain right next to 'modify.' I think this basic argument applies to a number of 'C++' features that for probably ten years we were assured not only that they were the 'better' ways to do things, but, in fact, they were they only possible way to accomplish things when scale was considered. This, of course, was preposterous, and even a cursory look at the fates of early large C++ projects that happened outside of Murray Hill will show a trail with some huge, abject disasters from companies like Mentor Graphics. I think some of the rigidity around this issue now is partially a reaction to the past, when C++ was going to cure cancer, and it turned out that, unless you happen to be Bjarne (not even going to give spelling his last name a go) or Andrew Koenig, et. al., C++ is a lot harder to do well, and a disaster waiting to happen for those who don't treat it well, with the irony of this being, it's the same reaction to both sides of the same coin. Also, some of the 'better ways' are very dubious when considered from either a risk or reward point of view. For example, using cout over printf(). Sure it's safer, but it's tedious as hell to write, massacres your source code because it takes a huge amount of space (relatively), especially when no one really cares about it or the printf it replaced, and I've yet to see the program that was brought to it's knees because of an invalid format spec, written by anyone who has ever gotten anything worth discussing or using out the door. Aside from the fact that even in error, a bad printf() statement is still essentially a debug trace that tells you where to look, if printf() is a deal breaker for you, your fate was decided a long time ago. As an aside, SAL is a crime against source code the world over. Readability of source code always comes before tools in my book. Much like the compiler, they too are own their own with me. I really like the capabilities of PREfast, and I think that both sides of the debate are very reasonable, but, for me, until it starts finding bugs that I can't find in other ways in a reasonable time frame, I'm not throwing my code and really my obsessive habits under the bus. I like tools that do what I want, not the other way around. Cheers, mm Oliver Schneider wrote: > Anton, Maxim, > > (Anton wrote:) >> So there is only one question left - do we really need all the above (and >> quite a few features beyond that) in the kernel mode??? > wrong question, IMO. The question more is whether *you* or *me* or anyone else him/herself or in team needs these features or finds them useful. It seems that the opponents of C++ in KM are quicker to tell *everyone* how to do what (i.e. not use C++), than the proponents are ;) > > (Maxim wrote:) >> For RAII code to be readable, your should declare only after {, so that >> {} will be the locked code path. Otherwise, the code reader will be <...excess quoted lines suppressed...>
  Message 41 of 108  
26 Jan 08 09:36
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: RE:c++
Actually, I can state that even though you feel inline declarations are good things, this was argued in the C++ standards committee whether it should be removed from the language! On one side were the folks saying it makes the code more reliable, and on the other side were the folks who argued that is makes accidents such as declaring X at the beginning of a function, then having an inline declaration of X, with the poor maintenance programmer missing the second declaration. Like a lot of things with C++ the arguments were long and heated, and in the end added nothing to the state of the art, since it was pointed out that long before C++ the same arguments happened for a number of other languages. -- 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" <xxxxx@gmxpro.net> wrote in message news:101152@ntdev... > Anton, Maxim, > > (Anton wrote:) >> So there is only one question left - do we really need all the above (and >> quite a few features beyond that) in the kernel mode??? > wrong question, IMO. The question more is whether *you* or *me* or anyone > else him/herself or in team needs these features or finds them useful. It > seems that the opponents of C++ in KM are quicker to tell *everyone* how > to do what (i.e. not use C++), than the proponents are ;) > <...excess quoted lines suppressed...>
  Message 42 of 108  
26 Jan 08 09:45
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: Re:c++
"Oliver Schneider" <xxxxx@gmxpro.net> wrote in message news:101129@ntdev... >> I don't, but since it appeared/appears that the majority of the frequent >> posters on NTDEV were/are opposed to C++ classes in KM, I thought I >> should show that there is a lot more besides the obvious. Actually classes are probably one of the few things that can be argued for, but even here there is a significant challenge. If you pin down the C++ and OO gurus they admit that when you have to fit an OO model into a system that has a lot of features but is not OO you either have to build a lot of infastructure code hiding the original system, of your model breaks down quickly. Mark Roddy and I both were involved with a multi-firm UNIX effort for a next-generation system, that included a number of folks who had worked at Bell Labs. Originally it was going to use C++ extensively, but in the end they had decided on almost a flat class structure, where there were simple classes for things like 64-bit integers, but otherwise mostly C style code. -- 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
  Message 43 of 108  
26 Jan 08 10:09
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
I was in Doron's office yesterday, and he suggested that we stick to discussing more important topics... such as whether you prefer to indent code with tabs versus spaces. I see the wisdom of his recommendation. Am I the only one? I'll start: I think tabs are "of the devil" and anybody who uses tabs is either stupid, an MVP, or hasn't searched the archives before posting. I'd like to know what product they're working on so I can avoid ever installing it on my system. And for those of you who think spaces are less efficient (multiple characters to process instead of just one tab character), you may have a point. But there was a paper a number of years back that said this wasn't true (unfortunately, it was written in Tagalog and I lost the citation -- there are so few really GOOD Tagalog web sites, anyhow). Kainin mo iyan, Peter OSR
  Message 44 of 108  
26 Jan 08 11:46
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
Peter, > I'll start: I think tabs are "of the devil" and anybody who uses tabs is either stupid, > an MVP, or hasn't searched the archives before posting. I'd like to know what > product they're working on so I can avoid ever installing it on my system. I appreciate you irony. The funniest thing here is that someone may take it seriously. More on it below... > And for those of you who think spaces are less efficient (multiple characters > to process instead of just one tab character), you may have a point. Believe it or not, there is "not-so-uncommon" belief among the newbies (mainly the ones who have migrated to to from VB and friends) that the more code you cram into a single line, the faster your program is going to run..... Anton Bassov
  Message 45 of 108  
26 Jan 08 11:49
Dan Kyler
xxxxxx@privtek.com
Join Date: 23 Jan 2004
Posts To This List: 165
RE: c++
It depends on what you mean. I prefer to indent my code by pressing the TAB key, which causes my editor to insert space characters. It gets really fun when one developer's editor is set to tabs and another's is set to spaces. On a related topic, why is the K&R brace placement style so damn popular? The only reason they used it was to save space in the book. Now it seems to be almost a universal standard, when anyone with half a brain can see that Allman style makes for code that can actually be read. - Dan. P.S. I suppose this response could also be considered a vote for top posting. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com Sent: Saturday, January 26, 2008 8:11 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] c++ I was in Doron's office yesterday, and he suggested that we stick to discussing more important topics... such as whether you prefer to indent code with tabs versus spaces. I see the wisdom of his recommendation. Am I the only one? I'll start: I think tabs are "of the devil" and anybody who uses tabs is either stupid, an MVP, or hasn't searched the archives before posting. I'd like to know what product they're working on so I can avoid ever installing it on my system. And for those of you who think spaces are less efficient (multiple characters to process instead of just one tab character), you may have a point. But there was a paper a number of years back that said this wasn't true (unfortunately, it was written in Tagalog and I lost the citation -- there are so few really GOOD Tagalog web sites, anyhow). Kainin mo iyan, Peter OSR --- 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
  Message 46 of 108  
26 Jan 08 12:13
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 760
Re: c++
I think the main reason for not using tabs is that it is not conistent. In a team env., when others looks at my code, they will see that I did not format it correctly. Spaces has the consistency. Also if think, the debugger ( Windbg ) gets totally lost, and shows the src is a very unformatted way when tabs are used. One other thing I like about VS IDE is to turn on the column boundary, so that statement does not go beyond some specified number of chars/line ( say 80 or 100 ) -pro ----- Original Message ----- From: "Dan Kyler" <xxxxx@privtek.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Saturday, January 26, 2008 8:49 AM Subject: RE: [ntdev] c++ > It depends on what you mean. I prefer to indent my code by pressing the > TAB > key, which causes my editor to insert space characters. It gets really > fun > when one developer's editor is set to tabs and another's is set to spaces. > > On a related topic, why is the K&R brace placement style so damn popular? > The only reason they used it was to save space in the book. Now it seems > to <...excess quoted lines suppressed...>
  Message 47 of 108  
26 Jan 08 12:45
Thomas Divine
xxxxxx@pcausa.com
Join Date: 05 Aug 2010
Posts To This List: 546
RE: c++
Peter, You must be joking, of course. You should know very well that there are much more important issues to be discussed. For example: 1.) Variable and procedure naming conventions. 2.) Use of PostScript language interpreters in the kernel. (I don't think anyone has brought this up before...). Think of PostScript as a general-purpose OO language. After MS research added the PS interpreter to the kernel at load time the driver would simply load the PS text and interpret it in real time. Tiny "driver". Whadya think? :-) Thomas F. Divine > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-312846- > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com > Sent: Saturday, January 26, 2008 10:11 AM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] c++ > > I was in Doron's office yesterday, and he suggested that we stick to > discussing more important topics... such as whether you prefer to <...excess quoted lines suppressed...>
  Message 48 of 108  
26 Jan 08 13:18
ntdev member 34909
xxxxxx@socket.net
Join Date:
Posts To This List: 17
RE: c++
Now wait a minute, Thomas. We haven't even discussed tab size yet... At 11:44 AM 1/26/2008, you wrote: >Peter, > >You must be joking, of course. You should know very well that there >are much more important issues to be discussed. For example: > >1.) Variable and procedure naming conventions. >2.) Use of PostScript language interpreters in the kernel. (I don't >think anyone has brought this up before...). > >Think of PostScript as a general-purpose OO language. After MS <...excess quoted lines suppressed...>
  Message 49 of 108  
26 Jan 08 13:54
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: RE:c++
> No question, references are more restrictive than pointers, but *that's* the feature, >otherwise it would be merely the clone of the functionality of pointers. Being not NULLable is a minor unimportant quirk, which surely cannot pay for lack of D& autocast to B&. What is important with references is lack of * and & operators, which makes returning lvalue or passing lvalue as parameter (the primary purpose of references) syntactically nice. >complain if the caller doesn't comply. I thought there was a broad consensus >among programmers that forcing compiler errors, where the alternative would be >runtime errors (which need handling and "~5 times more code to implement" ;) ...) >was a good thing. Depends. D* autocasts to B*, and D& does not autocast to B&. This is a by far more important then NULLability checks. >the original code with malloc/free (which is the kind of C I usally encounter in .cpp >files of the aforementioned kind of people) "is probably the best way of C++ use", Using exceptions and destructors to clean up after allocation failure _requires to wrap any allocated object into a C++ class with a destructor. For instance, HANDLE must be wrapped, all memory pointers must be wrapped, and so on. Otherwise you will have leaks on each exception. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 50 of 108  
26 Jan 08 13:57
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> would agree with, if that is in fact what he is saying. I don't use > references much myself, except in the case of overloaded operators, This is for what references were invented. > which I don't use much either and are for all practical purposes > unusable with out them, because they do not declare the intent or lack > there of to modify an argument, Correct. UpdateStructure(&S); is better then UpdateStructure(S); > considered from either a risk or reward point of view. For example, > using cout over printf(). cout is one of the worst C++ features, so, I always use printf even in C++ code. Using left shift operator for printing seems brain damage for me. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 51 of 108  
26 Jan 08 13:58
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> exception of 'Extreme Programming;' Well, this is PM's menace, not the developers menace :-) -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 52 of 108  
26 Jan 08 13:59
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
Thomas, > 2.) Use of PostScript language interpreters in the kernel. (I don't think anyone > has brought this up before...). I think this is going to be the next step. For the time being no one (yet) spoke about writing drivers in interpreted languages, but the managed ones are already there. Just search the web for Singularity project that is done by MSFT research - they are writing the whole OS in C#. Just pay a special attention to the performance tables - according to them, its performance is comparable to that of NT (on some operations is even better), with both Linux and FreeBSD, in all respects, dragging miles behind all MSFT OSes..... However, as Michael properly pointed out, before we can proceed to it we have to decide upon the tab size first - I think this factor must be of crucial importance to the OS that is written in any interpreted language, be it JavaScript or VBScript...... Anton Bassov
  Message 53 of 108  
26 Jan 08 14:00
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
>tabs versus spaces. Spaces. With this, the code looks the same regardless of the editor's settings on a particular desktop. GNU code uses tabs and assumes the tab width of 8. So, opening a GNU source file in MSVC, where the default is tab width 4, leads to funny results. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 54 of 108  
26 Jan 08 14:01
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> On a related topic, why is the K&R brace placement style so damn popular? ...and I cannot understand the space between "if" and "(", and never ever typed this space. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 55 of 108  
26 Jan 08 14:05
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
>2.) Use of PostScript language interpreters in the kernel. No, no, Haskell is smarter :) -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 56 of 108  
26 Jan 08 15:50
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 2663
Re: c++
Oh fine, but if you are going to post Microsoft's quasi official position on this, it should be qualified by the fact that concurrent to the release of this white paper, Microsoft was developing a C++ based object oriented driver framework, subsequently released as KMDF. Goose, gander. On Jan 25, 2008 4:52 AM, amitr0 <xxxxx@gmail.com> wrote: > 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 <...excess quoted lines suppressed...>
  Message 57 of 108  
26 Jan 08 19:14
David J. Craig
xxxxxx@yoshimuni.com
Join Date:
Posts To This List: 1114
Re: c++
Let's just make it 'better' and define the tab setting as zero. That would make it so much more 'interesting', although having an editor that randomly chooses a tab width with each invocation does seem even more 'interesting'. How about the random being applied randomly per file per invocation or switch to that file? Maybe have the editor do a 'beautify' of the 'C' code switching between the three main brace placements each time the file is opened? <xxxxx@hotmail.com> wrote in message news:101171@ntdev... > Thomas, > >> 2.) Use of PostScript language interpreters in the kernel. (I don't think >> anyone >> has brought this up before...). > > I think this is going to be the next step. For the time being no one > (yet) spoke about writing drivers in interpreted languages, but the > managed ones are already there. Just search the web for Singularity > project that is done by MSFT research - they are writing the whole OS in <...excess quoted lines suppressed...>
  Message 58 of 108  
26 Jan 08 22:19
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
<QUOTE> No, no, Haskell is smarter :) </QUOTE> Oh, no!! Not a Functional Programming Language. I almost brought this up during the previous discussion of APL (another Functional Programming Language), but I was busy being stern. I am sooooooo sick of hearing about Haskell and Erlang and F# from folks in the Digital Signal Processing area. "Well, Erlang is a great language, especially when coupled with OTP and it runs across many different platforms" -- YEAH... if you disable multiprocessor support it'll even run on Windows. Arrrrgh!! I'm entirely convinced that people really just wanna do something DIFFERENT. It doesn't need to be better. Well, except C#... which is clearly an improvement over C++, given that C++ is very obviously shit. That's my story, and... Peter OSR (OTOH, I like the idea of writing drivers in Postscript even better than the idea of writing drivers in C#. This'll let us write the documentation, and just interpret the driver at runtime. Clearly the wave of the future.)
  Message 59 of 108  
26 Jan 08 22:55
Faris Yau
xxxxxx@stg.com
Join Date: 06 Feb 2007
Posts To This List: 16
Re: c++
> I would completely agree with your assessment of "using the smart...," > and add that the situation is a party compared to what people who > learned C# first do, like have fifteen different singlets in one > program, and look at you like you are some out of your mind dinosaur if > you don't do the same. I recently had the misfortune of working on a C# program that was written like that. It was unpleasant. My eyes are still hurting.
  Message 60 of 108  
27 Jan 08 12:18
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 760
Re: RE:c++
While we are at it, Peter, here is my thoughts :-) I don't completely throw away the idea of functional programming. Sure, for kernel mode we are so used to advanced(structured) assembly ( ie., C) that I will have hard time conceptualizing the use of functional language in this environment, but again I don't know enough to throw the idea completely. In the research environment, sure they would like to do something new, different, .... But we all know, if something is really slick, it would fly sooner or later. Functional programming's main promise ( as I understood a quarter of a century ago ) is to have a provably correct program synthesis. In plain words, I write programs that would/could be verified for its correctness. This is certainly a good thing. Lot of these languages have either lack of expressiveness or difficult to express anything complex. And in earlier try, lot of them were interpretive. IIRC, there is a similarity between turing model and corresponding categorie theory for functional languages. And category theory is a branch of field theory, and it in turn is a branch of abstract algebra. In the last 20 years there are a lot of advance in these areas specially triggered towards functional programming. There the main emphasis is to have an automatic proof method.... This is a big thing for lot of programming areas. And the attack to this is not from kernel programming or user programming point of view, rather the proof of correctness is the angle of attack. And there are people who also does try to design machine architecture based on problem domain or language domain. An example is Belle ( the chase machine has quite a few HW level optimization for search techniques -- that I read a while ago ). On the pragmatic side -- 1) I would surely like to see automatic ( static) complexity analysis of a piece of code 2) Automatic proof of correctness of a piece of code. Perhaps, there is a lot of advances already in those area, I would not ever be able to be part of it. But I would love to see that comes forward and be used by commercial software.... This has its place :-) Finally, if anyone is thinking to buy a good book on programming "Beautiful Code" is one to look at! -pro ----- Original Message ----- From: <xxxxx@osr.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Saturday, January 26, 2008 7:20 PM Subject: RE:[ntdev] c++ > <QUOTE> > > No, no, Haskell is smarter :) > > </QUOTE> > > Oh, no!! Not a Functional Programming Language. I almost brought this up > during the previous discussion of APL (another Functional Programming > Language), but I was busy being stern. <...excess quoted lines suppressed...>
  Message 61 of 108  
27 Jan 08 15:11
ntdev member 26176
xxxxxx@writeme.com
Join Date:
Posts To This List: 252
Re: c++
"Maxim S. Shatskih" <xxxxx@storagecraft.com> wrote in message news:101172@ntdev... > >tabs versus spaces. > > Spaces. With this, the code looks the same regardless of the editor's settings > on a particular desktop. > > GNU code uses tabs and assumes the tab width of 8. So, opening a GNU source > file in MSVC, where the default is tab width 4, leads to funny results. Never say never, as the proverb goes. Once you're back to Linux, you're using the $#%^* tabs like everybody else and don't tweet - or you'll be shown the mother of Kuzma. duh. (sorry I couldn't resist) --PA
  Message 62 of 108  
27 Jan 08 16:24
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
True enough, Maxim. Maxim S. Shatskih wrote: >> exception of 'Extreme Programming;' > > Well, this is PM's menace, not the developers menace :-) >
  Message 63 of 108  
27 Jan 08 16:25
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
+1, Maxim. mm Maxim S. Shatskih wrote: >> would agree with, if that is in fact what he is saying. I don't use >> references much myself, except in the case of overloaded operators, > > This is for what references were invented. > >> which I don't use much either and are for all practical purposes >> unusable with out them, because they do not declare the intent or lack >> there of to modify an argument, > > Correct. <...excess quoted lines suppressed...>
  Message 64 of 108  
27 Jan 08 16:29
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Just as an aside, didn't APL originally require a special keyboard? My father used to ride to work on the train with Ken Iverson, and I seem to recall a story about this. Just wondering, mm Prokash Sinha wrote: > While we are at it, Peter, here is my thoughts :-) > > I don't completely throw away the idea of functional programming. > > Sure, for kernel mode we are so used to advanced(structured) assembly ( > ie., C) that I will have hard time conceptualizing the use of functional > language in this environment, but again I don't know enough to throw the > idea completely. > > In the research environment, sure they would like to do something new, <...excess quoted lines suppressed...>
  Message 65 of 108  
27 Jan 08 16:31
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Looking at this thread, Peter, it appears that some might want to consider taking Scott's advice about spending some time in the Northeast. mm xxxxx@osr.com wrote: > I was in Doron's office yesterday, and he suggested that we stick to discussing more important topics... such as whether you prefer to indent code with tabs versus spaces. I see the wisdom of his recommendation. Am I the only one? > > I'll start: I think tabs are "of the devil" and anybody who uses tabs is either stupid, an MVP, or hasn't searched the archives before posting. I'd like to know what product they're working on so I can avoid ever installing it on my system. > > And for those of you who think spaces are less efficient (multiple characters to process instead of just one tab character), you may have a point. But there was a paper a number of years back that said this wasn't true (unfortunately, it was written in Tagalog and I lost the citation -- there are so few really GOOD Tagalog web sites, anyhow). > > Kainin mo iyan, > > Peter > OSR <...excess quoted lines suppressed...>
  Message 66 of 108  
27 Jan 08 16:40
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 2732
Re: c++
Martin, Originally IBM made special terminals (both tty like and crt's) that had a custom keyboard and character set for APL. The couple of times I got exposed to APL, I remember the pain of trying to get time on one of a few terminals. -- 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 "Martin O'Brien" <xxxxx@evitechnology.com> wrote in message news:101212@ntdev... > Just as an aside, didn't APL originally require a special keyboard? My > father used to ride to work on the train with Ken Iverson, and I seem to > recall a story about this. > > Just wondering, > > mm
  Message 67 of 108  
27 Jan 08 18:00
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Thanks, Don. This must have been one seriously expensive keyboard, especially considering the time. Thanks, mm Don Burn wrote: > Martin, > > Originally IBM made special terminals (both tty like and crt's) that > had a custom keyboard and character set for APL. The couple of times I got > exposed to APL, I remember the pain of trying to get time on one of a few > terminals. > >
  Message 68 of 108  
27 Jan 08 18:26
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 760
Re: Re:c++
Martin, It's not just the keyboard ( of course the key board has the prints for all the alphabet special for APL, but there was also a ROM chip that you have had to plug-in to the mother board of a PC, and that was back when industry had to have a heavy lifting from 8086 to 80186 ). Before that what Don said was the method to use it, but I was not exposed to that env. -pro ----- Original Message ----- From: "Martin O'Brien" <xxxxx@evitechnology.com> Newsgroups: ntdev To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Sunday, January 27, 2008 1:28 PM Subject: Re:[ntdev] c++ > Just as an aside, didn't APL originally require a special keyboard? My > father used to ride to work on the train with Ken Iverson, and I seem to > recall a story about this. > > Just wondering, > > mm > Prokash Sinha wrote: >> While we are at it, Peter, here is my thoughts :-) <...excess quoted lines suppressed...>
  Message 69 of 108  
27 Jan 08 18:36
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Thanks, Pro. mm Prokash Sinha wrote: > Martin, > > It's not just the keyboard ( of course the key board has the prints for > all the alphabet special for APL, but there was also a ROM chip that > you have had to plug-in to the mother board of a PC, and that was back > when industry had to have a heavy lifting from 8086 to 80186 ). > > Before that what Don said was the method to use it, but I was not > exposed to that env. > <...excess quoted lines suppressed...>
  Message 70 of 108  
27 Jan 08 18:59
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> Just as an aside, didn't APL originally require a special keyboard? Actually, I don't think that you can use APL on a modern general-purpose kbd either. Certainly, due to the magic of UNICODE you must be able to configure fonts regardless of your kbd type, but typing APL characters on a normal general-purpose QWERTY must be just a nightmare - it must be the same experience as using QWERTY for typing in Arabic.... Anton Bassov
  Message 71 of 108  
27 Jan 08 19:11
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> Once you're back to Linux, you're using the $#%^* tabs like everybody else and > don't tweet - or you'll be shown the mother of Kuzma. What do you mean by "mother of Kuzma"???? Do you mean GNU compiler is going to take off the shoe and start hitting the table, promising to show you the one, i.e. do things the way some well-known character did in the United Nations back in 1960s??? Anton Bassov
  Message 72 of 108  
28 Jan 08 04:39
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 181
Re: c++
Can I recommend my practice of typing my inflamed response then deleting it before sending? Good for the psyche and forum congestion. M :-) this time is an exception.
  Message 73 of 108  
28 Jan 08 06:22
ntdev member 33991
xxxxxx@tx.rr.com
Join Date:
Posts To This List: 154
Re: c++
Wrong thread, but obviously that was directed at me... I've replied to Mike off-list, if anyone else cares too - email your grievances to me off-list - if you care too. I promise I'll be nice.... My apologies for polluting everyone's inbox - I was indeed being an ass the other morning. It's hard to be nice when your an asshole.... :-) Best wishes to almost everyone, Matt ----- Original Message ----- From: "Mike Kemp" <xxxxx@sintefex.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Monday, January 28, 2008 3:38 AM Subject: Re: [ntdev] c++ > Can I recommend my practice of typing my inflamed response then deleting > it > before sending? Good for the psyche and forum congestion. M :-) this time > is an exception. > > > --- > NTDEV is sponsored by OSR > <...excess quoted lines suppressed...>
  Message 74 of 108  
28 Jan 08 11:16
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
<QUOTE> Can I recommend my practice of typing my inflamed response then deleting it before sending? </QUOTE> There is a lot to be said for this practice. I can honestly say that I delete more postings to this list than I send. By quite a large margin, in fact. This includes some really long, and even some technical, ones. Peter OSR
  Message 75 of 108  
28 Jan 08 11:31
ntdev member 26176
xxxxxx@writeme.com
Join Date:
Posts To This List: 252
Re: c++
<xxxxx@hotmail.com> wrote in message news:101220@ntdev... >> Once you're back to Linux, you're using the $#%^* tabs like everybody else and >> don't tweet - or you'll be shown the mother of Kuzma. > > What do you mean by "mother of Kuzma"???? Do you mean GNU compiler is going to take off > the shoe and start hitting the table, promising to show you the one, i.e. do things the way > some well-known character did in the United Nations back in 1960s??? > > Anton Bassov Anton, I mean only the linuxoidal coding style. The compiler by itself is ok. It wasn't noticed wearing shoes and does not enforce any particular coding style by itself (though it has some great features that make code written to this compiler easy visible). The rest is the history and offtopic... --PA
  Message 76 of 108  
28 Jan 08 12:15
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
I'm sort of glad to learn that I'm not the only person who does this, perhaps not as often as I should. mm xxxxx@osr.com wrote: > <QUOTE> > Can I recommend my practice of typing my inflamed response then deleting it before sending? > </QUOTE> > > There is a lot to be said for this practice. > > I can honestly say that I delete more postings to this list than I send. By quite a large margin, in fact. This includes some really long, and even some technical, ones. > > Peter > OSR <...excess quoted lines suppressed...>
  Message 77 of 108  
28 Jan 08 12:37
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> Anton, I mean only the linuxoidal coding style. The compiler by itself is ok. What does annoy me about it is a coding style of GNU assembly - I find writing "movl $var,%eax/n" instead of simply "mov eax,var", i.e. in the reverse order of arguments, really abominable (I don't even mention $ and % prefixes, as well as /n on every line)... Anton Bassov
  Message 78 of 108  
28 Jan 08 12:42
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 5070
Re: c++
Dan Kyler wrote: > It depends on what you mean. I prefer to indent my code by pressing the TAB > key, which causes my editor to insert space characters. It gets really fun > when one developer's editor is set to tabs and another's is set to spaces. > Please help me write a file system upper filter driver to change all the tabs to spaces in every file that I write. My boss says that's the only way it can be done, so that's what I need. Oh, and I have to have a solution by Friday, so a pointer to working and fully commented code is needed or else I will be fired. Thanks in advance! -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 79 of 108  
28 Jan 08 12:47
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Also very difficult to read, unless of course you learned it first, I suppose. But even in that case, as you pointed out, the AT&T syntax is a little verbose, and differs from the Intel manual, which I think is pretty bizarre, as assembler is not usually where one expects to find language design at a tool level. I suppose whoever first implemented gas preferred it, which for most of us, I think at least, turned out to be unfortunate. mm xxxxx@hotmail.com wrote: >> Anton, I mean only the linuxoidal coding style. The compiler by itself is ok. > > What does annoy me about it is a coding style of GNU assembly - I find writing > "movl $var,%eax/n" instead of simply "mov eax,var", i.e. in the reverse order of arguments, really abominable (I don't even mention $ and % prefixes, as well as /n on every line)... > > Anton Bassov >
  Message 80 of 108  
28 Jan 08 12:55
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 5070
Re: c++
xxxxx@hotmail.com wrote: >> Anton, I mean only the linuxoidal coding style. The compiler by itself is ok. >> > > What does annoy me about it is a coding style of GNU assembly - I find writing > "movl $var,%eax/n" instead of simply "mov eax,var", i.e. in the reverse order of arguments, really abominable (I don't even mention $ and % prefixes, as well as /n on every line)... > But that is only because you are used to the Intel/MASM syntax. Had you "grown up" using the AT&T syntax with many other processors, there wouldn't be anything annoying at all about it. And, indeed, you would be able to read 80x86 assembly code written in that style and have a pretty good idea what it did, even if you had never seen the 80x86 instruction set before. Many participants of this list have lost the distinction between "things that are bad because I don't like them" and "things that are inherently bad". -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 81 of 108  
28 Jan 08 13:42
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1602
RE: c++
+1 ;-) I guess this list would be better place if *some* people learn this technique, too. 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 Martin O'Brien[SMTP:xxxxx@evitechnology.com] > Reply To: Windows System Software Devs Interest List > Sent: Monday, January 28, 2008 6:15 PM > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] c++ > > I'm sort of glad to learn that I'm not the only person who does this, > perhaps not as often as I should. <...excess quoted lines suppressed...>
  Message 82 of 108  
28 Jan 08 15:06
greg jacklin
xxxxxx@hotmail.com
Join Date: 03 Apr 2003
Posts To This List: 56
Re: c++
may I suggest a filter driver that plugs in to the filter manager FS upper filter driver, that way you don't take up another stack location :) do you need this to be transaction aware? you may just want to let yourself be fired... finding a new job can be easier than writing a good FS filter driver. -------------------------------------------------- From: "Tim Roberts" <xxxxx@probo.com> Sent: Monday, January 28, 2008 9:41 AM To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: Re: [ntdev] c++ > Dan Kyler wrote: >> It depends on what you mean. I prefer to indent my code by pressing the >> TAB >> key, which causes my editor to insert space characters. It gets really >> fun >> when one developer's editor is set to tabs and another's is set to >> spaces. >> > > Please help me write a file system upper filter driver to change all the <...excess quoted lines suppressed...>
  Message 83 of 108  
28 Jan 08 17:39
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> But that is only because you are used to the Intel/MASM syntax. Well, what syntax are you supposed to get used to if you deal with *INTEL* processor, apart from Intel assembly??? > Had you "grown up" using the AT&T syntax with many other processors, > there wouldn't be anything annoying at all about it. Well, if I was dealing with some other processor I would not find it annoying at all, no matter how different its syntax is from the one I am accustomed to. However, when I deal with x86, I expect x86 syntax. To give you an idea, would you prefer to make your posts in English or in some "neutral" language like Esperanto??? Anton Bassov
  Message 84 of 108  
28 Jan 08 18:26
ntdev member 8437
xxxxxx@windows.microsoft.com
Join Date:
Posts To This List: 1404
RE: RE:c++
A common practice I suspect. Often just typing up the rant is sufficient to help one relax. And it's a much less expensive practice than my old one of destroying keyboards in a "hulk smash" style fit of rage. -p -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com Sent: Monday, January 28, 2008 8:18 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] c++ <QUOTE> Can I recommend my practice of typing my inflamed response then deleting it before sending? </QUOTE> There is a lot to be said for this practice. I can honestly say that I delete more postings to this list than I send. By quite a large margin, in fact. This includes some really long, and even some technical, ones. Peter OSR --- 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
  Message 85 of 108  
28 Jan 08 18:41
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 5070
Re: c++
xxxxx@hotmail.com wrote: >> Had you "grown up" using the AT&T syntax with many other processors, >> there wouldn't be anything annoying at all about it. >> > > Well, if I was dealing with some other processor I would not find it annoying at all, no matter how > different its syntax is from the one I am accustomed to. However, when I deal with x86, I expect x86 syntax. There is no such thing. Syntax is defined by the assembler, not by the processor. NASM, FASM, MASM, A86, and others all use slightly different syntax. Even the syntax used in Intel's manuals does not match the syntax MASM expects. > To give you an idea, would you prefer to make your posts in English or in some "neutral" language like Esperanto??? > If I were writing posts on an Esperanto forum, I'd expect to have to write in Esperanto in order to be understood. Similarly, if one is writing assembly language for a Unix system, one should expect to use the Unix assembler syntax. The processor is irrelevant in that discussion. You are looking at this from the point of view of a weathered MASM jockey suddenly being thrust into a Linux world. The much more common case (until recently) was the point of view of the weathered Unix hacker now trying to get his kernel stuff working on an x86 processor. That hacker knows the AT&T syntax, and just needs to learn the x86 opcode names. Linux has skewed this demographic, because its easy availability has meant that huge swarms of DOS- and Windows-trained MASM programmers started experimenting with Linux. The gcc folks had to capitulate by introducing an "Intel syntax" option, which the gas assembler now supports. You would find that syntax much more familiar. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 86 of 108  
28 Jan 08 22:30
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
<QUOTE> There is no such thing. Syntax is defined by the assembler, not by the processor. NASM, FASM, MASM, A86, and others all use slightly different syntax. </QUOTE> Indeed! In fact, as far as constructing a reasonably good assembler language, MASM sucks seriously. Almost as much as C++ sucks as a high level language, but not quite so much. I remember Borland TASM, which had something called "ideal mode" -- VERY much more consistent, less cryptic, and easier to read. Sadly, the operands still moved right to left, which IMHO is contrary to G-d's intended design... which was of course, manifest in the perfection that is (was) PDP-11 assembler language. Peter OSR
  Message 87 of 108  
28 Jan 08 22:31
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
>>However, when I deal with x86, I expect x86 syntax. > There is no such thing. Syntax is defined by the assembler, not by the processor. NASM, FASM, > MASM, A86, and others all use slightly different syntax. Even the syntax used in > Intel's manuals does not match the syntax MASM expects. I am afraid you are confusing assembly (i.e. bare-bone instruction set without any directives) and *MACRO* assembler. All above mentioned things are macro assemblers that are, indeed, slightly different from one another. However, all these assemblers are based upon Intel assembly, i.e. instruction set as it is described in Intel Manuals. In Intel assembly, first, destination and source operands come respectively first and second, and, second, the same instruction can be used regardless of operand size. However, GNU assembler goes further than just being different from other macro assembler - it turns the instruction set itself upside down > If I were writing posts on an Esperanto forum, I'd expect to have to write > in Esperanto in order to be understood. Exactly. Similarly, if you want your *assembly* code to be understood, you may expect to write it in instruction set as it is defined by CPU manufacturer, rather than turning it upside down. > Similarly, if one is writing assembly language for a Unix system, > one should expect to use the Unix assembler syntax. Again, this holds only for macro assembler (i.e. directives). However, I would expect the instruction set itself to match the one defined by the CPU manufacturer.. > You are looking at this from the point of view of a weathered MASM jockey suddenly > being thrust into a Linux world. The much more common case (until recently) > was the point of view of the weathered Unix hacker now trying to get his kernel > stuff working on an x86 processor. That hacker knows the AT&T syntax, and just > needs to learn the x86 opcode names. Despite highly provocative "C vs C++" name, this thread has not yet had a "flame war" that one would normally expect on it. The funniest thing here is that we are about to start a "flame war" ( which is hardly surprising for the thread with so provocative name) on a totally different topic that one would normally expect to see in a UNIX NG, rather than here - "AT&T syntax vs Intel syntax".... Anton Bassov
  Message 88 of 108  
28 Jan 08 22:39
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> Well, what syntax are you supposed to get used to if you deal with *INTEL* ? >processor, apart from Intel assembly??? gas uses portable assembler syntax. I expect that you even can use %1 instead of %eax there. Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 89 of 108  
28 Jan 08 22:39
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> the operands still moved right to left, which IMHO is contrary to G-d's intended design... It was just made conform to Intel instruction set as it is described in Intel Manuals. GNU seems to be the first assembler that challenges this part... Anton Bassov
  Message 90 of 108  
28 Jan 08 22:51
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: c++
> I am afraid you are confusing assembly (i.e. bare-bone instruction set >without >directives) and *MACRO* assembler. No. These are not macros. The assembly language features of: - lexical style of register names (prefixes etc) - lexical style of labels - lexical style of hardcoded numbers - lexical style of denoting the addressing operators ([] or such) - order of operands - are not CPU-dependent. Yes, assembler is a CPU-dependent language, but the lexical issues above can be made portable, and this is what gas does. The only nonportable things are opcode names, code generation sequence for each opcode and the per-opcode operand requirements. With such an approach, gas can easily be ported to generate the code for any new CPU in the world. I dunno on what CPU gas has originated, maybe on 680x0 family (as most GNU/UNIX software), which is claimed to be the most direct successor of glorified PDP-11 line. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 91 of 108  
28 Jan 08 23:06
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> The only nonportable things are opcode names, code generation > sequence for each opcode and the per-opcode operand requirements. Exactly. As long as your assembler for x86 conforms to "MOV r/m(size),r(size) - MOV r(size) , r/m(size) -etc" style as it is described in Intel Manuals, there is nothing wrong with it. However , when you start changing the order of operands and introduce your own instructions that don't exists in x86 instruction set (i.e. MOVB, MOVS, MOVL and MOVQ "variations on the theme" of MOV), you already screw it up (at least in my understanding of things) , because you already don't conform to the original instruction set... Anton Bassov
  Message 92 of 108  
29 Jan 08 07:35
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 1371
RE: c++
Ah, macro-11. You could teach that assembler to do just about anything. I taught it to generate DG-Nova code 'cause, well, I was young, in a hurry, dumb, and didn't have a nova assembler but was awash in PDP-11s. Now I have done my part to spiral this thread into oblivion and will now shut up. -dave -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com Sent: Monday, January 28, 2008 10:32 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] c++ <QUOTE> There is no such thing. Syntax is defined by the assembler, not by the processor. NASM, FASM, MASM, A86, and others all use slightly different syntax. </QUOTE> Indeed! In fact, as far as constructing a reasonably good assembler language, MASM sucks seriously. Almost as much as C++ sucks as a high level language, but not quite so much. I remember Borland TASM, which had something called "ideal mode" -- VERY much more consistent, less cryptic, and easier to read. Sadly, the operands still moved right to left, which IMHO is contrary to G-d's intended design... which was of course, manifest in the perfection that is (was) PDP-11 assembler language. Peter OSR --- 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
  Message 93 of 108  
29 Jan 08 08:00
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 181
Re: RE:c++
Can someone clarify? Is asm permitted in Kernel Mode? Thx, M
  Message 94 of 108  
29 Jan 08 09:02
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
<QUOTE> Is asm permitted in Kernel Mode? </QUOTE> Permitted? Yes. Discouraged and a bad idea, except for certain very specific instances? Also yes. Peter OSR
  Message 95 of 108  
29 Jan 08 10:34
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Also, on x64, CL does not support inline assembler, if that's what he's after. mm xxxxx@osr.com wrote: > <QUOTE> > Is asm permitted in Kernel Mode? > </QUOTE> > > Permitted? Yes. Discouraged and a bad idea, except for certain very specific instances? Also yes. > > Peter > OSR > >
  Message 96 of 108  
29 Jan 08 11:16
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 181
Re:c++
I think that it is necessary to build all drivers now for 64 bit as well as 32 bit OS, so does this mean excluding asm altogether? Or is there an approved MASM or equivalent for kernel use? So far I have avoided using assembler but I am now considering whether it is worth it to optimise some core routines and/or to use the DSP type instructions available in the latest CPUs. Thanks for any views.. Sorry if this is off topic, but it has been about assemblers for the last few days so got me thinking. Mike. >>>>> From: Martin O'Brien Newsgroups: ntdev To: Windows System Software Devs Interest List Sent: Tuesday, January 29, 2008 3:34 PM Subject: Re:[ntdev] c++ Also, on x64, CL does not support inline assembler, if that's what he's after. mm xxxxx@osr.com wrote: > <QUOTE> > Is asm permitted in Kernel Mode? > </QUOTE> > > Permitted? Yes. Discouraged and a bad idea, except for certain very > specific instances? Also yes. > > Peter > OSR > <...excess quoted lines suppressed...> --- 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
  Message 97 of 108  
29 Jan 08 11:33
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
Definitely on topic, and certainly more so than anything else in this thread. You can use assembler in the kernel, but on x64 (using Microsoft tools) you must compile assembler seperately, and can not use inline assembler in C or C++. That is, assembler must be in it's own source file. The WDK comes with x86_32 and x86_64 (and Itanium, perhaps) versions of ML (MASM). I don't recall exactly how one does this with BUILD, but I seem to recall something about placing the file in an architecture subdirectory and adding to SOURCES, but that may not be correct. Check the WDK documentation for this. Good luck, mm Mike Kemp wrote: > I think that it is necessary to build all drivers now for 64 bit as well > as 32 bit OS, so does this mean excluding asm altogether? Or is there an > approved MASM or equivalent for kernel use? So far I have avoided using > assembler but I am now considering whether it is worth it to optimise > some core routines and/or to use the DSP type instructions available in > the latest CPUs. Thanks for any views.. Sorry if this is off topic, but > it has been about assemblers for the last few days so got me thinking. > Mike. > >>>>>> <...excess quoted lines suppressed...>
  Message 98 of 108  
29 Jan 08 11:38
ntdev member 28798
xxxxxx@comcast.net
Join Date:
Posts To This List: 218
RE: c++
> does this mean excluding asm altogether? No, only the inline one is out for 64 bit. You still can have your *.asm compiled separately. > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-313138- > xxxxx@lists.osr.com] On Behalf Of Mike Kemp > Sent: Tuesday, January 29, 2008 11:15 AM > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] c++ > > I think that it is necessary to build all drivers now for 64 bit as > well as <...excess quoted lines suppressed...>
  Message 99 of 108  
29 Jan 08 11:40
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 6526
Re: Re:c++
> 32 bit OS, so does this mean excluding asm altogether? Only inline __asm in C/C++ code. >Or is there an > approved MASM or equivalent for kernel use? Yes. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com
  Message 100 of 108  
29 Jan 08 11:58
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 181
Re:c++
Thanks, that's very useful info. This is only at the "what if" stage at the moment but a lot of what I do is speculate in what is possible for the next bright idea (and if I'm unlucky, implementing it). I had misunderstood that asm was out. Now I think it will be possible to create a BSOD faster than ever before. M >>>>>>>>> From: Martin O'Brien Newsgroups: ntdev To: Windows System Software Devs Interest List Sent: Tuesday, January 29, 2008 4:33 PM Subject: Re:[ntdev] c++ Definitely on topic, and certainly more so than anything else in this thread. You can use assembler in the kernel, but on x64 (using Microsoft tools) you must compile assembler seperately, and can not use inline assembler in C or C++. That is, assembler must be in it's own source file. The WDK comes with x86_32 and x86_64 (and Itanium, perhaps) versions of ML (MASM). I don't recall exactly how one does this with BUILD, but I seem to recall something about placing the file in an architecture subdirectory and adding to SOURCES, but that may not be correct. Check the WDK documentation for this. Good luck, mm Mike Kemp wrote: > I think that it is necessary to build all drivers now for 64 bit as well > as 32 bit OS, so does this mean excluding asm altogether? Or is there an > approved MASM or equivalent for kernel use? So far I have avoided using > assembler but I am now considering whether it is worth it to optimise some > core routines and/or to use the DSP type instructions available in the > latest CPUs. Thanks for any views.. Sorry if this is off topic, but it > has been about assemblers for the last few days so got me thinking. Mike. > >>>>>> > From: Martin O'Brien <...excess quoted lines suppressed...> --- 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
  Message 101 of 108  
29 Jan 08 12:25
MM
xxxxxx@evitechnology.com
Join Date: 28 May 2005
Posts To This List: 2209
Re: c++
No problem. Good luck, mm Mike Kemp wrote: > Thanks, that's very useful info. This is only at the "what if" stage at > the moment but a lot of what I do is speculate in what is possible for > the next bright idea (and if I'm unlucky, implementing it). I had > misunderstood that asm was out. Now I think it will be possible to > create a BSOD faster than ever before. M > >>>>>>>>>> > From: Martin O'Brien > Newsgroups: ntdev > To: Windows System Software Devs Interest List <...excess quoted lines suppressed...>
  Message 102 of 108  
29 Jan 08 14:22
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 2475
List Moderator
RE: c++
<QUOTE> Sorry if this is off topic, but it has been about assemblers for the last few days so got me thinking. </QUOTE> The only disappointing part of the last few postings to this thread has been that I haven't been able to think of anything sarcastic or even remotely funny to say. I wouldn't have expected that in a thread about C++ or even a thread about which brand of assembler is good and which is evil. Now, please... can we get back to discussing something meaningful, like whether K&R indenting is part of some type of long-planned yet still dormant terrorist plot? Peter OSR
  Message 103 of 108  
29 Jan 08 15:47
Ray Trent
xxxxxx@synaptics.spamblock.com
Join Date: 25 Aug 2003
Posts To This List: 392
Re: c++
I have to say that I've been sitting here LMAO for the last 10 minutes at the "turn about is fair play" way this C++ thread has been hijacked. xxxxx@osr.com wrote: > <QUOTE> > Sorry if this is off topic, but it has been about assemblers for the last few days so got me thinking. > </QUOTE> > > The only disappointing part of the last few postings to this thread has been that I haven't been able to think of anything sarcastic or even remotely funny to say. > > I wouldn't have expected that in a thread about C++ or even a thread about which brand of assembler is good and which is evil. > > Now, please... can we get back to discussing something meaningful, like whether K&R indenting is part of some type of long-planned yet still dormant terrorist plot? > <...excess quoted lines suppressed...> -- Ray (If you want to reply to me off list, please remove "spamblock." from my email address)
  Message 104 of 108  
29 Jan 08 16:06
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> The only disappointing part of the last few postings to this thread has been > that I haven't been able to think of anything sarcastic or even remotely funny to say As Mark said, hijacking threads becomes a norm here. Apparently, it applies both ways - threads that are meant to be "good" (judging from the title) turn out to be stupid, and, funny enough, the opposite seems to be true as well.... In the very beginning of this thread, one of the posters questioned its very purpose - he said that most people on this list are fed up with reading the same arguments again and again and again. However, this thread somehow managed to grow beyond 100 posts, with vast majority of them made by the "regulars".... Anton Bassov
  Message 105 of 108  
29 Jan 08 16:09
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
Ray, > I have to say that I've been sitting here LMAO for the last 10 minutes at the > "turn about is fair play" way this C++ thread has been hijacked We have arrived to the same conclusion simultaneously - you made your post while I was typing mine.... Anton Bassov
  Message 106 of 108  
30 Jan 08 03:57
ntdev member 2587
xxxxxx@ixos.de
Join Date:
Posts To This List: 21
RE: c++
> In the very beginning of this thread, one of the posters questioned its very > purpose - he said that most people on this list are fed up with reading the same > arguments again and again and again. However, this thread somehow managed to > grow beyond 100 posts, with vast majority of them made by the "regulars".... > Anton Bassov hi Anton, that was me. But meanwhile this thread is really funny to read. It developed in such a way, that I have to withdraw my argument above ;-)) -- Reinhard
  Message 107 of 108  
30 Jan 08 21:43
ntdev member 26176
xxxxxx@writeme.com
Join Date:
Posts To This List: 252
Re: c++
<xxxxx@hotmail.com> wrote in message news:101299@ntdev... >> the operands still moved right to left, which IMHO is contrary to G-d's intended design... Hmm... perhaps right to left _is_ G-d's intended, it's same direction as in Hebrew :) --PA
  Message 108 of 108  
30 Jan 08 22:07
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 2691
RE: c++
> Hmm... perhaps right to left _is_ G-d's intended, it's same direction as in Hebrew :) ..and, which is even more important in context of this discussion, in x86 assembly as it is described in Intel Manuals.... Anton Bassov
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 13:50.

Contact Us - Osr Online Homepage - Top

Copyright ©2005, OSR Open Systems Resourcs, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license