Reply to: .NET overloads/shadows

[ASB]

although I think it might well be shadows.

Yes I think it is the equivalent. But I get exactly the same issue in VB. Have to recompile to client to notice.

[Weltchy]

There is no such command as overloads in C# (or rather, you have no need to use it). If you have the same method name but with a different interface in C#, the compiler automatically picks up the fact. The new class modifier keyword in c# essentially hides the base class's implementation of a method with the same interface and points towards the new method in the implementing class. I don't know what the equivalent keyword in VB is, although I think it might well be shadows.

[VectraMan]

But since it allows the overloading of non virtual virtual functions this does indeed mean all functions should be treated precisely this way.

Ultimate the compiler is trying to offer flexibility, just doesn't quite explain the implications.

I don't agree; the problem here is about Exes and DLLs, nothing to do with the compiler. Exactly the same would happen in C++.

[xoggoth]

Dunno, I am just about to release a new product using VB.net and it all works pretty well but I never undertand all that technical jargon about overloads and late binding etc.

[ASB]

B.Something will be called, if it exists. The compiler, when compiling the client end, looks for Something in B, doesn't find it, then looks for one in the base class, does find it, so inserts code to call that.

B.Something will be called if it happened to exist at compile time. So yes in order to cope with it it would have to treat all functions as virtual.

But since it allows the overloading of non virtual virtual functions this does indeed mean all functions should be treated precisely this way.

Ultimate the compiler is trying to offer flexibility, just doesn't quite explain the implications.

[VectraMan]

Well, I wouldn't argue with much of that. Except for "and when the function doesn't exist in B". Since the client is calling B.Something I don't think it is entirely unreasonable to expect B.Something to be called.

B.Something will be called, if it exists. The compiler, when compiling the client end, looks for Something in B, doesn't find it, then looks for one in the base class, does find it, so inserts code to call that.

The other way it could work is for the compiler to write a stub for B.Something to call A.Something and every other function that might be overidden, just so that a future build of the B code could then override it. Which would obviously introduce a large overhead.

I guess what you're saying is you want that logic to exist at load time, not necessarily at runtime (like a virtual function). That means the loader needs to know about OOP and inheritance, which isn't really its job.

[ASB]

You are talking about overloads (same method name, different parameters) or overrides (same method signature, but replacing the definition in a base class).

Everyone seems to be mixing overloads and overrides and I ain't got a clue what's going on.

It didn't help that I downed 10 pints last night and got about 4 hours sleep either.

To paraphrase VectraMan I'm cheating and been bitten.

It's an overload with the same parameters (equivalent to "new" I think in C#). [I guess the fundamental problem is being allowed to overload a method in a base class with a method in a derived class with an identical signature]

[ASB]

Don't know about VB, or .NET for that matter, but how else is going to work? If it's not virtual it means it's a straight function call, and when the function doesn't exist in B it's a straight call to the one in A. It can't know in advance that you're going to do something different later.

You're expecting the compiler to insert some extra code to look for a derived version at runtime, which is exactly what happens with virtual functions.

So the answer is a) use virtual, or b) deploy the things that need to be deployed.

It's perfectly okay for this to be allowed; it would never be a problem in a single EXE or DLL. It's only because you're trying to combine one half of the program with another half from a previous build, and haven't designed it to allow that.

Well, I wouldn't argue with much of that. Except for "and when the function doesn't exist in B". Since the client is calling B.Something I don't think it is entirely unreasonable to expect B.Something to be called.

[DimPrawn]

C#

You are talking about overloads (same method name, different parameters) or overrides (same method signature, but replacing the definition in a base class).

Everyone seems to be mixing overloads and overrides and I ain't got a clue what's going on.

It didn't help that I downed 10 pints last night and got about 4 hours sleep either.

[Weltchy]

Hrm,

In C#, i'd change the overloads to new. I'll give this a go when I get some time and see what happens. I've got a funny feeling I've run across this before, just have to remember what i changed

[VectraMan]

Don't know about VB, or .NET for that matter, but how else is going to work? If it's not virtual it means it's a straight function call, and when the function doesn't exist in B it's a straight call to the one in A. It can't know in advance that you're going to do something different later.

You're expecting the compiler to insert some extra code to look for a derived version at runtime, which is exactly what happens with virtual functions.

So the answer is a) use virtual, or b) deploy the things that need to be deployed.

It's perfectly okay for this to be allowed; it would never be a problem in a single EXE or DLL. It's only because you're trying to combine one half of the program with another half from a previous build, and haven't designed it to allow that.

[ASB]

I may have the wrong end of the stick here, but it is how the compiler determines which overload to call when there is some ambiguity.

http://blogs.extremeoptimization.com...2/10/7134.aspx

http://msdn2.microsoft.com/en-us/library/tb18a48w.aspx

There is no ambiguity, it's when the binding actually happens which is the problem.

public class A
Function fx as String
return "from base"
end function
end class

public class B Inherits A
end class

And the client code

sub Main

dim ob as new b
console.write ob.fx

end sub

This is all fine.

Now I change B as

public class B Inherits A
overloads function fx as string
return "From Derived"
end class

Build and deploy B.

Behaviour is unchanged. Oops.

Rebuild the client and it now calls the overload.

So, what I think is happening is that at compile time the function is resolved as an IL.CALL. Thus it will call whatever was resolved at compile time. Because it is not marked as overridable it is not producing a CALLVIRT.

When the client is recompiled it resolves to the overload in the derived class. Again with an IL CALL.

It seems to me that Overloads - of a base class method - should not be allowed when the base class method is not virtual. Because this is going to break existing clients. [Unfortunately in VB at least the compiler demand you overload it].

To be fair, you'll never see the the problem in testing. Only in partial deployment.

[DimPrawn]

I may have the wrong end of the stick here, but it is how the compiler determines which overload to call when there is some ambiguity.

http://blogs.extremeoptimization.com...2/10/7134.aspx

http://msdn2.microsoft.com/en-us/library/tb18a48w.aspx

[ASB]

Hrm,

That doesn't sound right. I've had a derived class with an overloaded method call correctly without having to recompile the client code. Are you sure the reference is pulling from the correct place, and its not running from a version in the GAC?

Absolutely sure (but that doesn't make me right!).

Obviously it's not possible to reproduce it in the IDE without twiddling build setting etc. Heres how to do it (for the terminally bored).

- Create a baseclass with a "SomeMethod" returning "from base".
- Create a derived class
- Create a client, instance derived class and write result or some method to console

Copy exe and dll somewhere convenient.
Run it.

- Now update the derived class to overload the method returning "from derived"
- Copy new derived class
- Run and watch in amazement as it fails to call the overload. [Or laugh at my expense of course]

Recompile the client and now it will call the overload.

Now, maybe this is because it is VB (but I don't think so, it happens with Cobol as well). But it most definitely occurs on my machine which VS2005 SP1.

[Weltchy]

Hrm,

That doesn't sound right. I've had a derived class with an overloaded method call correctly without having to recompile the client code. Are you sure the reference is pulling from the correct place, and its not running from a version in the GAC?