Mark :
So the only advance is a virtual functions ? Never used it in my drivers
and never feel a need for
this. The OS is another issue but still OS does have verified and well
implemented mechanism ,
and once it’s implemented a don’t see any reason to switch language
especially if missing part is already implemented.
I still think that MDL is very good example since MDL implementation is
more object oriented than you can achieve
in c++, and again may be i wrong since i don’t know c++ i only make my
conclusions from your (and other folks)
c++ advantage examples this is the reason why i want to see an example of
better c++ implementation for this.
Alberto :
If I were Microsoft, I would have structured MDLs as a list of objects
I really don’t care how Microsoft will implement this internally probably i
even don’t want to know how it’s implemented as long as i have good api to
work with object, this is the whole point of object oriented correct me if
i wrong here.
I want to see what advantage i will have as a user if i will have c++
object instead of c object. As example for disadvantage:
A need to recompile the entire project instead of relink when something
internal is changed in MDL implementation.
A small one i a agree, but i want to know what i get what i got in advantage?
Regards Ilya.
At 12:24 PM 8/12/2003 -0500, you wrote:
MDL’s are a bad example. A good example is a driver that needs to support
multiple types of DeviceObjects. A good design, independent of toolset used,
will implement an object oriented solution that provides both default and
device-type specialized dispatching methods. C++ is simply a better language
for implementing such a design than is C, as the compiler has built into it
standard, efficient, and verified mechanisms for generating such function
dispatching tables. You can of course ‘roll your own’ in C, but why?Even Microsoft is grudgingly (and glacially) moving in the direction of
accepting C++ as a valid and useful toolset for kernel development.=====================
Mark Roddy> -----Original Message-----
> From: Ilya Lifshits [mailto:xxxxx@jungo.com]
> Sent: Monday, December 08, 2003 12:09 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] RE: how to ensure atomic code in a kernel mode driver
>
> Alberto,
>
> Take the MDL object as example and describe how can you make
> it better with c++ And i mean make it better not replace
> IoAllocateMdl with new because there is no real advantage
> here. I’m not pretend to know c++, never write more than few
> lines in c++, but i read carefully all your holly war for
> last few years and i never seen a real life advantage in c++
> side of war examples :). So here a real object, implemented
> in c, for my opinion clean object oriented one, just show me
> any advantage in implementing this object in c++.
>
> Regards Ilya.
>
>
> At 10:27 AM 8/12/2003 -0500, you wrote:
> >Let me give you guys a few suggestions.
> >
> >You call it Driver “object”, no ? Device “object” ? Make it
> so ! Real
> >objects, I mean. Make the driver stack an object too, make
> the Irp have
> >a member function that returns a reference to the stack. Remove all
> >need to pass Driver Object or Device Object as a parameter
> by using the
> >kinds of techniques employed by MFC to make templates out of
> documents and views.
> >Bury memory allocation inside the objects, so that we never have to
> >invoke any allocator function directly and we never have to
> worry about
> >which pool we getting data from: if an object requires the nonpaged
> >pool, for example, that should be buried inside the object
> itself through overriding the “new”
> >operator. Make partially opaque data structures into objects and use
> >attributes such as “private” and “protected” to hide what you don’t
> >want the rest of the world to see. Use inheritance to derive Irp
> >objects from other Irp objects. Define all interfaces as abstract
> >classes, COM style. Define objects for all relevant hardware
> entities:
> >buses, bridges, dma, agp, processor, you name it, and make those
> >objects behave like OS monitors, multiprocessor safe: the
> serialization
> >is inherent to the object and needs not be negotiated by the
> >programmer, it comes automatically. Give us a coherent
> interface into the runtime, like for example what we have in STL.
> >Give us polymorphic versions of the API functions, so that
> we can omit
> >unnecessary parameters from the function calls and thus reduce the
> >possibility of error.
> >
> >This and other things, would make writing drives a breeze.
> >
> >
> >Alberto.
> >
> >
> >-----Original Message-----
> >From: xxxxx@lists.osr.com
> >[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
> >Sent: Friday, December 05, 2003 6:38 PM
> >To: Windows System Software Devs Interest List
> >Subject: [ntdev] RE: how to ensure atomic code in a kernel
> mode driver
> >
> >
> >Since this relates to code I was directly (and indirectly)
> responsible
> >for I feel compelled to say that C++ would have been of little help
> >here.
> >
> >I guess we might have written an allocator class for certain
> structures
> >that could keep some back-pocket resources to ensure we can make
> >progress on one i/o request at a time. Instead we wrote a set of
> >functions to do it. Doing it with the class keyword would
> have added
> >little.
> >
> >Overriding operator-new so we didn’t define new allocator functions
> >would also provide little - either we pass in enough new
> data at each
> >invocation of operator-new to tell it to follow the
> work-in-low-memory
> >semantics, or we check the value when operator-new comes back and do
> >something special. Encapsulating it in a set of functions
> was just as
> >good as operator-new. And if you stick to a good function naming
> >scheme you can get most of the benefits of methods anyway.
> >
> >OOP design paradigms are what are valuable here. If using an “OOP”
> >language without the associated OOP paradigms is not helpful, then
> >perhaps it’s not the language that’s providing the benefits.
> >
> >-p
> >
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: xxxxx@lists.osr.com
> >[mailto:xxxxx@lists.osr.com] On Behalf Of
> Moreira, Alberto
> >Sent: Friday, December 05, 2003 1:26 PM
> >To: Windows System Software Devs Interest List
> >Subject: [ntdev] RE: how to ensure atomic code in a kernel
> mode driver
> >
> >…
> >
> > >Given the amount of labour MS did to the disk stack on XP (NO
> > >resources
> >
> > >are allocated in critical IO paths) - I can hardly imagine
> C++ to be
> > >suitable
> >for
> > >such a task.
> >
> >Let me put it this way: doing the XP stack in C++ would entail a lot
> >less work.
> >
> >…
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >The contents of this e-mail are intended for the named
> addressee only.
> >It contains information that may be confidential. Unless you are the
> >named addressee or an authorized designee, you may not copy
> or use it,
> >or disclose it to anyone else. If you received it in error please
> >notify us immediately and then destroy it.
> >
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as: xxxxx@jungo.com To
> >unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@jungo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com