Sign in to follow this  
HugosHoH

[.net] Virtual?! Asynch!?

Recommended Posts

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.

Share this post


Link to post
Share on other sites
1. Something must be abstract or virtual to use override. Trying to use override on something that is not virtual/abstract will result in a compilation error. Not using the override keyword will allow you to create a method of the same name to "hide" the inherited virtual method, and the IDE (at least I believe it does... I know ReSharper does at least) will point this out since its generally not something you want to do.

2. I haven't done a whole lot of anything special with the WinForms, but pretty sure that just about everything involving the WinForms and controls are (and must be) run in a single thread.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
It's the same thing in C#. Use virtual in the base class and override in the derived class(es).


public class Foo
{
virtual void printMe()
{
System.Console.Writeln("I'm the base class");
}
}

public class Bar : Foo
{

override void printMe()
{
System.Console.Writeln("I'm the derived class");
}

public static void Main( )
{
Foo example = new Bar();
example.printMe(); //will print, "I'm the derived class"
}
}

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:

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.

I am seriously beginning to think that all you do is start threads simply so that you can attempt to peddle this kind of misinformed idiocy around the forums. What part of you are wrong do you not get?

C# is compiled to an intermediate form. C# code itself is not interpreted. The CIL might be interpreted (mono can do this), but most production-quality CLR implementations, such as mono and .NET, JIT-compile the CIL. That means they read the CIL once and turn it into native code, and subsequent exectutions use native code. This is fundamentally distinct from interpreting the code, which does not translate what it is interpreting. It reads, parses and executes it directly, and will always do so even on subsequent calls to the same method, et cetera.

Java, FWIW, can be JIT-compiled as well nowadays, although I don't know how widespread JIT-compiling runtimes are.

Quote:

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

C# is statically typed. You can reflect type information dynamically at runtime, but you can do this in C++ as well (C# simply does it better and provides more information). So you're wrong again here, and either way this has nothing to do with being interpreted or not. Nor does a garbage collector (garbage collection, furthermore, has performances implications, but its foolish to imply that garbage collection as a whole, in general, is 'slow.' You collect garbage in C++ too, you just do it manually. Depending on what you do, you may be more or less efficient than a generic automatic collector; it really depends).

Share this post


Link to post
Share on other sites
Quote:
Original post by HugosHoH
Java and C# are pretty in the same boat...out of question. and Java is interpreted as all references and text books say.
Many books about Java were written fairly long ago, when it really was interpreted. CIL has never been interpreted on the MS implementation, and Mono uses the interpreter only as a testing platform, it's not the normal execution method.
Quote:
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
Those have nothing to do with interpreted vs executed. (Oh, and there's no dynamic type checking except when casting. And you can add GC to C++ if you want.)
Quote:
the interpreter does not gives executable image, it just run the code.
The JITter generates executable code directly to memory, and then submits it directly to the processor. An executable image IS generated, and you can even see the exact native (x86) assembly code if you want. It's just not generated to a file -- at least, not one you can easily find.

Besides, you clearly don't know how to program that well, let alone knowing C#. What the hell makes you think you have the background to understand or evaluate this sort of thing? I've seen Python code rape C++ for speed at certain tasks, and Python typically IS interpreted, so obviously this is far more subtle than "interpreted = slow". In other words, it'd be a good idea to stop talking now. You already have a history of trolling C# for no apparent reason, and you're a post away from being banned.

Share this post


Link to post
Share on other sites
You don't insult my experience and knowledge just because I have a different view of this script called C#. It seems that you don't know much about languages and compiler concepts :D

there's a book called C# for dummies :D, this makes sense to me :D :D :D

Share this post


Link to post
Share on other sites
Quote:

I have a different view of this script called C#

Your 'view' is fundamentally incorrect. The nature of the language, and the computer science concepts involved in this discussion thus far, in general, are not matters of opinion. They're clearly and objectively defined; yet you seem to want to persist in trying to subvert them with your own subjective re-interpretations.

No matter how many times you plug up your ears and scream "la la la I can't hear you," that will not change the fact that C# is not an interpreted language on any major production-quality platform in existence, for the standard and well-accepted definitions of 'interpreted.'

Quote:

there's a book called C# for dummies :D, this makes sense to me :D :D :D

Comments like this only serve to reinforce my growing suspicion that you're just here to troll. Please refrain from making these sorts of rim shots in the future.

Share this post


Link to post
Share on other sites
This all comes down to the same saying; "It is a poor artist that blames his tools." C# has a very good performance as long as you understand what performance issues there are with some calls. But that is the same with every language out there. Yes C++ can be brought to a crawl also if you write bad code.

theTroll

P.S. Stop insulting us "real" trolls by including people like him with us.

Share this post


Link to post
Share on other sites
When .NET runs the JIT on the CIL generated from the C# compiler, it reads through it, quickly optimizes it with optimizations available on the target computer, and runs it. .NET has also added a background optimizer service that will produce the native image for .NET programs without having to run them. So interpreted? No. If anything, it is interpreted at some point, sometimes. But I don't know if even that falls into the category of interpreted. Basically you are just compiling twice - once from the language to CIL, then another time when the application is on the target machine.

As far as performance goes, that is a pretty stupid argument unless you even need it. Yes, better performance is always nice. But who cares how fast your code runs if you never even finish it. The kind of optimizations that actually matter are the ones compilers can not do for you - how you approach the problem.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this