Uniprocessor really has nothing to do with it. Yes, the message is sent one at a time to an application, but the same happens if it's multi-processor. The message the window gets is serialized because the message queue and a single threaded window proc make it that way. The keyboard interrupt is free to generate another scan code/send the next byte when the the interrupt handler sends the EOI (End Of Interrupt) control. This happens almost immediately after you've read the key scan code from the port. Then the key is put into the keyboard buffer and sent off to generate the message. While that is going on, the keyboard is still a hardware device that can interrupt a thread's processing (just like anything else) based on it's current IRQL. So, even on a single processor, the next key press could be retrieved and processed all before the application ever gets dispatched the first key. The only thing the multi-processor could do is if the first processor got caught on a disk I/O and is at high IRQL, the other processor could handle the next keyboard interrupt at the same time. However, after the Disk I/O was done the keyboard would have gone and done it's turn before the thread was allowed to reschedule to a lower IRQL anyway. The other funny thing is that actually one processor could be delievering the current key while the other one is processing the next, so it actually could make the situation worse since if it was single processor the hardware interrupt would definately interrupt the keystroke delivery while processing the other key. This is a minor detail though, processing a scan code is farily quick. Pressing multiple keys the keyboard ends up continously generating one of the keys usually, the last one pressed. So a series of keystrokes could be: (Make Code) UP (Make Code) DOWN (Make Code) DOWN (Make Code) DOWN (Break Code) UP (Break Code) DOWN So, even though both keys are pressed the second action is continous so depending on how the application handles this it could move the cursor up then continously down because the application doesn't track the UP key's state. The UP key never provided a break code (key unpress) yet. So, it depends on how the application tracks the keyboard state. There are also special keys, I don't remember if the keyboard itself handles these or it if was solely a process done by the BIOS, but as you know certain keys maintain a "shift" type state, such as Alt, Control and Shift. It's been a while since I wrote a keyboard filter driver though or

Because for one thing, your example is not exception-safe. If in the "..." code an exception is thrown, you'll end up with a memory leak. Since the topic has the subject "about delete" I only mention that there is no difference between delete and delete[]. You may assume that "..." stands for the following: try { // do something meaningful } catch (...) { } Of course you can use finally to free memory... :rose: Or you just use a wrapper class which ctor does this for you (so you can't forget)... Or use managed C++ :laugh:

It's because call() takes the paramater by value and not by reference. Because you've declared it to take the parameter by value, the passed object gets *sliced*. So even if you pass an instance of derived, it gets sliced and only the base part of the objects is passed to call. The sum function call then executes on the sliced base instance and so you get 47 and not 57 Regards Senthil _____________________________ My Blog | My Articles | WinMacro