I've a couple of Q's: 1 - How does C#'s new override help? What case? Why declaring something virtual is pointless unless it's declared override in the derived class? Then what's the purpose of virtual keyword? 2 - Are the WinForms message handlers run asynchronous? For example, when sending a WM_PAINT like message to refresh the form's client area, is it run in a separate thread? Thanks.

so there's no point of the keyword virtual.
and what do u mean by hiding an implementation? example?

some programmers assume the message handling in .NET is asynch. I'm not sure yet where to find reliable info...if any wants to release that anyway.

Quote:
so there's no point of the keyword virtual.

Yes, there is. The virtual keyword indicates the method is available for dynamic dispatch, in the base (controlling) class. Non-virtual methods are dispatched statically; regardless of whether or not they are overridden, the variant that is dispatched is the variant corresponding to the static type of the object calling the method.

So virtual has a use, to indicate that dynamic dispatch is necessary. It does not make sense for this to be a default, always-on behavior since there is a penalty (in size and performance, although it is minor and largely amortized) for the functionality. Plus it does not make semantic sense, as allowing all methods to be so customized makes it more difficult to ensure class invariants.

Quote:
and what do u mean by hiding an implementation? example?

Shadowing, essentially. A override marked "new" hides an override higher in the class hierarchy; the 'new' is a clarification, a way to ensure that you really meant to do what you typed, which is sometimes dangerous. This is an improvement over C++'s method of not requiring you to specify that a method is hiding another which can introduce subtle bugs, especially due to the variations of cv-qualifiers in C++.

Quote:
Are the WinForms message handlers run asynchronous? For example, when sending a WM_PAINT like message to refresh the form's client area, is it run in a separate thread?

The events that execute for things like Paint, Clicked, et cetera are simply multicast delegate invocations. They execute on the UI thread, and it's generally a sane idea to keep all such UI work on the UI thread, as that's how the API was designed.

That said, the API is asynchronous the same way the native Win32 API is (that is, via multiplexing; it does not spin up worker threads to send you WM_PAINT and the like). The underlying pump operation in WinForms is more or less the same pump as used in Win32.

It is possible to invoke the delegates on worker threads, and perform UI work from multiple threads, and there are a few cases where it makes sense. Double check that that's not what the code is doing.

In C++, specifying a method as virtual tells the compiler no need to optimize when using pointers or references of objects since we are calling the right method for the object not the type, and the only way to do this is by virtual tables, which requires pointers. So virtual here is a way to override. Otherwise it's pointless and inefficient to call by pointers.

Now C#. when I use virtual and I don;t override, then what's the point? What does it tell the compiler or, the interpreter to be precise, to do? If I have to use override keyword anyway?

What do u mean by hiding/shadowing base implementation? Just one example please.

Quote:
In C++, specifying a method as virtual tells the compiler no need to optimize when using pointers or references of objects since we are calling the right method for the object not the type, and the only way to do this is by virtual tables, which requires pointers. So virtual here is a way to override. Otherwise it's pointless and inefficient to call by pointers.

No, in C++ and C# 'virtual' does exactly the same thing: it indicates that calls to the method in question should be resolved based on the dynamic type of the invoking object ("what it really is at runtime") versus the static type ("what the type written at compile time is"). It has nothing to do with optimization beyond the neccessary, and the exact nature of the implementation (virtual tables, et cetera) are implementation-detail that the languages do not concern themselves with. And furthermore, virtual function tables are not the "only" way to implement dynamic dispatch -- they're just the most popular way.

Quote:
Now C#. when I use virtual and I don;t override, then what's the point? What does it tell the compiler or, the interpreter to be precise, to do? If I have to use override keyword anyway?

The same point as when you use virtual in C++ but don't override. 'virtual' is applied to the base (or most-base) variant of the function in question. In C++, all overrides (if any) are then implicitly virtual as well. In C#, you must mark each override with the override keyword, as a way of indicating that you intended to override it (which helps avoid the aforementioned subtle bugs).

Your question is malformed. If, in C#, you mark a function virtual but don't override, you never need the 'override' keyword. 'virtual' methods that are not overridden are perfectly sane -- you may be writing a library, or other middleware, that expects client code to subclass and override those methods even though your code does not. 'virtual' indicates, essentially, that you are allowing this function to be dispatched at runtime. Without virtual, you are denying that privilege.

Furthermore, C# is not interpreted, so your "to be more precise" annotation is in fact inaccurate. It gets compiled to CIL, which may be interpreted, but is usually then JIT-compiled to native code.

Quote:
What do u mean by hiding/shadowing base implementation? Just one example please.

See here.

Still makes none sense. Yes C# is an interpreted language until we have something like a label on the CPU ".NET enabled," or the GC is made part of the system, not the platform.

Quote:
Still makes none sense.

Why not?

Quote:
Yes C# is an interpreted language until we have something like a label on the CPU ".NET enabled," or the GC is made part of the system, not the platform.

No, you're wrong. You're trying to redefine what 'interpreted' means. That's not your call.

Java and C# are pretty in the same boat...out of question. and Java is interpreted as all references and text books say. The same applies to C# even if MS wants the opposite, it still has a GC and dynamic type checking at run time...intermediate code...so yes it's interpreted and slow :D

Java -> compiler -> bytecode -> interpreter (VM)

C# -> compiler -> CIL -> interpreter (JIT)

the interpreter does not gives executable image, it just run the code.