469,266 Members | 2,014 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,266 developers. It's quick & easy.

abstract class 'does not implement interface member ...'

I get
C:\Programming\LTM\devtools\UselessJunkForDissasse mbly\Class1.cs(360,27):
error CS0535: 'UselessJunkForDissassembly.InvocableInternals' does not
implement interface member
'UselessJunkForDissassembly.IInvocableInternals.Op erationValidate(string)'
C:\Programming\LTM\devtools\UselessJunkForDissasse mbly\Class1.cs(360,27):
error CS0535: 'UselessJunkForDissassembly.InvocableInternals' does not
implement interface member
'UselessJunkForDissassembly.IInvocableInternals.Pr oxiedOperation'

when compiling:
public interface IInvocable
{
object Operation { get; }
}
internal interface IInvocableInternals : IInvocable
{
bool OperationValidate(string args);
string ProxiedOperation { get; }
}
public abstract class InvocableInternals : IInvocableInternals
{
public object Operation { get { return ProxiedOperation; } }
}

But, I already knew the class didn't implement those functions. That's why
it is *abstract*. Please note that I've replaced all complicated types with
object or string to make a minimal reproduction. I don't want my internal
functions exposed publicly, I can't hide InvocableInternals because public
classes inherit from it, and I don't want to use a forwarder because, I'm
convinced that the JIT wouldn't be able to inline it.
Why isn't it allowed to just implement
"IInvocableInternals.OperationValidate" in the most derived class?
Jun 11 '07
52 20119

"Christof Nordiek" <cn@nospam.dewrote in message
news:uj**************@TK2MSFTNGP05.phx.gbl...
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamschrieb im Newsbeitrag
news:OO**************@TK2MSFTNGP03.phx.gbl...
>>>>You could try following
>
public abstract class InvocableInternals: IInvocableInternals
{
string IInvocableInternals.ProxiedOperation{get {return
ProxiedOperation;}}
>
internal abstract string ProxiedOperation {get;}
>
......
}

I know you can, but adds extra layers of indirection at runtime,
entirely needlessly.
Maybe, but only, because the implementors of C#/.NET didn't consider it
worth to optimize this away. I don't see why this should work different
in runtime.

I don't see how it can avoid being different at runtime. In order for
the JIT to remove the function call, it would have to inline the code,
and it doesn't have enough information for that.
Given that we compare explicit implementation of abstract class with
calling an abstract method in an explicit method:
In the first scenario the interface member has to be mapped to an method
wich itself is an entry in a v-table.
In the second scenario the runtime sees that the method is nothing more,
than a call of a virtual/abstract method and could transform this call in
absolute the same manner as in the first scenario.

Am I missing something?
The abstract class explicit interface implementation will be called through
an interface, so it must be an entry in a v-table. The derived class
implementation is polymorphic (potentially many classes derived from the
abstract class), so it must be dispatched through the v-table as well.

If you could use "internal abstract ReturnType Method(arguments)" to
implement the interface, then the derived class method could be stored in
the interface v-table and invoked on the first dispatch. I don't see how
this is possible using the shim layer. You think that the JIT does reverse
inlining, where the interface v-table entry gets replaced by a derived
method that combines the base implementation with the (now known) inlined
derived instance? But that would break reflection, so I'm quite sure it
isn't being done.

public delegate void SimpleDelegate();

internal interface ISecret
{
void TellLocation();
}

public abstract class SecretBase : ISecret
{
abstract internal void TellLocation();
void ISecret.TellLocation() { TellLocation(); }
}

public class SecretHideout : SecretBase
{
internal void TellLocation() { ... }
}

public class SecretFortress : SecretBase
{
internal void TellLocation() { ... }
}

ISecret hideout = new SecretHideout();
ISecret fortress = new SecretFortress();

SimpleDelegate tell1 = hideout.TellLocation;
SimpleDelegate tell2 = fortress.TellLocation;

Assert.AreSame(tell1.Method, tell2.Method);
Now, can you suggest any way for the JIT to eliminate the second v-table
dispatch without breaking the assertion? With the alternate syntax, the
assertion would be expected to fail, but here there is only one
implementation of ISecret.TellLocation so it must succeed.
Jun 20 '07 #51
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamschrieb im Newsbeitrag
news:%2****************@TK2MSFTNGP04.phx.gbl...
>
public delegate void SimpleDelegate();

internal interface ISecret
{
void TellLocation();
}

public abstract class SecretBase : ISecret
{
abstract internal void TellLocation();
void ISecret.TellLocation() { TellLocation(); }
}

public class SecretHideout : SecretBase
{
internal void TellLocation() { ... }
}

public class SecretFortress : SecretBase
{
internal void TellLocation() { ... }
}

ISecret hideout = new SecretHideout();
ISecret fortress = new SecretFortress();

SimpleDelegate tell1 = hideout.TellLocation;
SimpleDelegate tell2 = fortress.TellLocation;

Assert.AreSame(tell1.Method, tell2.Method);
Now, can you suggest any way for the JIT to eliminate the second v-table
dispatch without breaking the assertion? With the alternate syntax, the
assertion would be expected to fail, but here there is only one
implementation of ISecret.TellLocation so it must succeed.
When generating the v-table entry for ISecret in class SecretHideout it
detects, that the implementation simply delegates the call to another
method. Then it lets the v-table entry point directly to that method.

If that really gives a performance boost in many cases, I'm sure they would
implement such optimization.

BTW: Do you have any evidence, that this isn't implemented in that way and
that this rises performance issues? Until now our discussion is only
theorie.

Christof
Jun 25 '07 #52

"Christof Nordiek" <cn@nospam.dewrote in message
news:eT**************@TK2MSFTNGP04.phx.gbl...
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamschrieb im Newsbeitrag
news:%2****************@TK2MSFTNGP04.phx.gbl...
>>
public delegate void SimpleDelegate();

internal interface ISecret
{
void TellLocation();
}

public abstract class SecretBase : ISecret
{
abstract internal void TellLocation();
void ISecret.TellLocation() { TellLocation(); }
}

public class SecretHideout : SecretBase
{
internal void TellLocation() { ... }
}

public class SecretFortress : SecretBase
{
internal void TellLocation() { ... }
}

ISecret hideout = new SecretHideout();
ISecret fortress = new SecretFortress();

SimpleDelegate tell1 = hideout.TellLocation;
SimpleDelegate tell2 = fortress.TellLocation;

Assert.AreSame(tell1.Method, tell2.Method);
Now, can you suggest any way for the JIT to eliminate the second v-table
dispatch without breaking the assertion? With the alternate syntax, the
assertion would be expected to fail, but here there is only one
implementation of ISecret.TellLocation so it must succeed.

When generating the v-table entry for ISecret in class SecretHideout it
detects, that the implementation simply delegates the call to another
method. Then it lets the v-table entry point directly to that method.

If that really gives a performance boost in many cases, I'm sure they
would implement such optimization.

BTW: Do you have any evidence, that this isn't implemented in that way and
that this rises performance issues? Until now our discussion is only
theorie.
Only that the optimization you describe is illegal because it would break
the example code I gave. Note that possibly Assert.AreSame is the wrong
test, really whether the MethodToken is the same is what matters.
>
Christof

Jun 25 '07 #53

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

17 posts views Thread by Medi Montaseri | last post: by
4 posts views Thread by C.E.O. Gargantua | last post: by
10 posts views Thread by Joe | last post: by
18 posts views Thread by Bradley | last post: by
9 posts views Thread by Sean Kirkpatrick | last post: by
6 posts views Thread by Steve | last post: by
reply views Thread by mailforpr | last post: by
reply views Thread by emin.shopper | last post: by
5 posts views Thread by Tony Johansson | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.