> 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.
Okay. I see we are on the same ship. (I wonder if you Englishs understand this phrasis as me.) > > 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. Nice object oriented symphony. > 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. Oh, get back to the ground. I've never heard about CPU as an object. But I had this on my mind too, some years ago. But when I told this at school, they sent me to the psychiatrist. So either we think on different abstraction level, or it's really stupid. I thougt CPU as a resource, which would be allocated like the memory, soundcard or anything else. (*like* - not the same) > 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. How we can discuss this, when you is the only man who have seen the source code? I think all computers use some virtual (or 'scan') key codes, so the keyboard system can be built up from some callbacks, and 'update' function called each frame. In 'update', the driver can call callbacks for each key pressed/released during the last frame, giving the key code and its state. Key codes can be virtual, allowing some national-keyboard support, and of course allowing to have 99% of code platform independent. > > 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. I call this 'big pink pig'. :-))) What a poet am I. It was a hard work, wasn't it? If I programmed it, I select one particular fullscreen mode (or two), and do nothing more..... Of course it's great. I personally would spend time with other features, which are to be implemented. (I like especially overlay option - it's crazy! SimCoupe is the only emulator which has this feature.) > > 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! Okay, I don't argue. > > (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 Of course. But I preffer classes with static methods over namespaces (dots, instead of 4-dots :))) If namespaces would allow top use dots (like Turbo Pascal does for names in units), I would preffer them. regards, Aley
