Aley Keprt wrote: > This is unfair. > You very probably know than C++ is not intended to be used for writing > device drivers, and saying this.
Actually, all but one of my kernel-mode drivers are written in C++! It's harder work as you have to start by defining your own new/delete operators, but it's pretty straight-forward after that. The NT/WDM model suits it very well, with the device object data as the data the object manipulates, etc. I've done the same for VxDs, but only using the VtoolsD toolkit which mainly involves thunks to set up 'this' before the member functions are called - pretty simple to use it again. > SimCoupe is typical modular application (CPU, keyboard, disk > drive, display, mouse, ...). > Although modular = "good for C-language", but it would be much better > written in C++. It does suit it, which is why it's already written like this in many areas - I've got CIoDevice (abstract) base, with I/O handling objects derived from that for various peripherals. I've then got derived classes such as CPrinterDevice, CMonoDACDevice, CStereoDACDevice, etc. The disk types are also classes derived from CDisk, as are the disk data streams to allow sourcing data from compressed files, devices etc. transparently to the core. C++ does suit some of it very well, but it's too easy to get carried away and spoil things. In theory the CPU could be an object too, to allow pluggable CPU cores, etc. but that would introduce an extra level of abstraction in a timing-critical component, and introduce a potentially huge speed penalty. All C would be unnecessarily messy (or result in a 'C' abstraction of C++), and _all_ C++ would be over the top, but a balance in-between seems to suit SimCoupe as a specific case. Input remains a self-contained platform-specific module which is called once a frame to do any device reading necessary to update the SAM keyboard and mouse states. It could be moved into objects, but I didn't think it'd really give any extra value in doing so - the SAM input I/O is all pretty intertwined anyway. > This would allow very simple porting, since we can have a > predecessor class display, which would be derived into several > (i.e. 1 or more ;-) classes for particular display types. > (If necessary.) The memory image of the SAM display is built up using C++ template classes to give optimal classes that reduce the number of run-time decisions needed. However the display itself is (currently) another single module, which leaves the platform-specific implementation to do whatever is necessary for whatever modes of output are supported. I'm still changing this at the moment - for an automatic 'accurate mode 3' option. > Also, classes would allow us to quite easily divide program into > portable and system-dependant parts. I'd like to think it's close to this stage already! > (note: Interfaces can be implemented by either classes or > namespaces in C++.) For the single modules I've been using namespaces to give a 'nicer' interface to the modules that do not use classes. It avoids cluttering the global namespace, and Input::Init() somehow seems nicer than InitInput() etc. :-) Si
