Explicit interface implementation compiler bug in VS 2003?

[Martin Zenkel]

Assumed two assemblies (one C# and one C++), C++ refers
to C#. The follwing code compiles and works well under VS
2002! VS 2003 C++ compiler reports the error

"error
2555: 'TestNamespace::ClassB::IInterfaceB.get_Content':
overriding virtual function return type differs and is
not covariant from 'TestNamespace::ClassA::get_Content'"

Explicit implementation of "IInterfaceA.Content" in
ClassA avoids the compiler error.

Two questions:
Why does this error occur in C++ (and with C# not)?
Why does explicit implementation "solve" the problem?


content of C# assembly:
-----------------------
using System;

namespace TestNamespace
{
public interface IInterfaceA
{
string Content
{
get;
}
}

public interface IInterfaceB
{
int Content
{
get;
}
}


public class ClassA : IInterfaceA
{

// string IInterfaceA.Content
// {
// get { return ""; }
// }

public string Content
{
get { return ""; }
}
}

public class ClassC : ClassA, IInterfaceB
{
int IInterfaceB.Content
{
get { return 0; }
}
}
}
------------------------


content of C++ assembly:
------------------------
#pragma once

namespace TestNamespace
{

public __gc class ClassB : public ClassA, public
IInterfaceB
{
public:

__property int IInterfaceB::get_Content()
{
return 0;
}

};

}
------------------------

 

[Gary Chang [MSFT]]

HI Martin,

Thanks for posting in the group!

If you have looked up the documentation of the error C2555 on MSDN, you
could find the following explanation:
"A virtual function and a derived overriding function have identical
parameter lists but different return types. An overriding function in a
derived class cannot differ from a virtual function in a base class only by
its return type."

So in your situation, the VC++ 7.1 compiler cannot determine whether the
"__property int IInterfaceB::get_Content(){...}" is the implementation of
the TestNamespace::::IInterfaceB.get_Content or
TestNamespace::IInterfaceA::get_Content, they have the same function name
and without parameter, only different from the return type.

BTW, I am not familiar with the C#, but I think in C# an overriding
function in a derived class can differ from a virtual function in a base
class only by its return type.


Best regards,
Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Martin Zenkel]

Hello Gary,

thank you for your reply.

I understand the error message of the c++ compiler
completely. But it should not occur, because using the
line

__property int IInterfaceB::get_Content()

in ClassB I stated clearly that I want to implement the
property "Content" of the interface "IInterfaceB".

The c++ compiler of VS 2002 was able to understand this
as well as the c# compiler (see implementation of ClassC).

The most strange thing is if i implement the "Content"
property of "IIntefaceA" in ClassA explicitly then the
c++ compiler reports no error although the functions
which have caused the error are still there.

 

[Gary Chang [MSFT]]

Hi Martin,

Thanks for your quickly response!

From my point of view, if you implement the "Content" property of
"IIntefaceA" in ClassA explicitly, the compiler can fit your implementation
of the property "Content" (in VC assembly) only to interface
"IInterfaceB", for the reason that "Content" property of "IIntefaceA"
already have a explicit implementation.

I noticed something deferent in the Class View Tab when you explicit
implementation of "IInterfaceA.Content" in ClassA (C# Assembly).


Best regards,
Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Martin Zenkel]

Hi Gary,

Thanks again for your reply!

From my point of view, if you implement the "Content" property of
"IIntefaceA" in ClassA explicitly, the compiler can fit your implementation
of the property "Content" (in VC assembly) only to interface
"IInterfaceB", for the reason that "Content" property of "IIntefaceA"
already have a explicit implementation.

This is true of course. This fact is quite simple to
understand. But unfortunately this is not an answer to
the question of this thread.
Let me put the leading question into other words:
"ClassA" declares and implements "Content". "IInterfaceB"
declares "Content" too (assumed with completly other
meaning). "ClassB" derives from "ClassA". And it
additionally implements "IInterfaceB", which means to
implement "Content". Why is this not possible in C++?

Further question: Can you (as MS-partner) try to compile
this code using the current Whidbey alpha version?

Best regards,
Martin Zenkel

 

[Gary Chang [MSFT]]

Hi Martin,

Thanks for your reply!

"ClassA" declares and implements "Content"

In the class view tab, I can see the "Content" entry , not the
"IInterfaceA.Content", so I think "public string Content{...}" doen't
implement the IInterfaceA.Content, it seems like a member property of the
ClassA .

If I discomment the explicit implementation code of "IInterfaceA.Content",
then I can see the "IInterfaceA.Content" entry appears. This is what I want
to express in my last post.

For compile the code in Whidbey alpha version, I will reply you the result
in a few days.

Best regards,
Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Gary Chang [MSFT]]

Hi Martin,

I have test your sample code in the current Whidbey Beta
version(m2.xxxxxx-xxxx), and under this new version, it has been compiled
with no error occurring.

Best regards,
Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Martin Zenkel]

Hi Gary,

Thanks again for your quick reply!

...I think "public string Content{...}" doen't
implement the IInterfaceA.Content

1.) Assuming you (and the class view) are right:
In this case I am very surprised NOT to get the compiler
error "error CS0536: 'TestNamespace.ClassA' does not
implement interface
member 'TestNamespace.IInterfaceA.Content'." (Of course
class view tells us, that ClassA implements its
own "Content" and doesn't implement IInterfaceA.Content.
IMHO class view and compiler information are not
consistent concerning this point. In the end there is no
other option than trustng the compiler, which produces
our runtime code.)

But strictly speaking our initial question hasn't as much
to do with ClassA rather than ClassB.

2.) Again with other words, the original question to our
example:
We get the compiler error "error
C2555: 'TestNamespace::ClassB::IInterfaceB.get_Content':
overriding virtual function return type differs and is
not covariant from 'TestNamespace::ClassA::get_Content'".
In ClassB we declare that ("IInterfaceB!!!::get_Content")
is what we are going to implement. Why is the compiler
still "thinking" that we want to
override "ClassA::get_Content"???

Apart from this:
It WORKS with the previous version (VS2002). It WORKS
with the next version (Whidbey Beta, thank you for
testing). It DOESN'T WORK with the current version
(VS2003)!

Best regards,
Martin Zenkel

 

[Martin Zenkel]

Hi Gary,

I have test your sample code in the current Whidbey Beta

Thank you very much.

Best regards, Martin Zenkel

 

[Yan-Hong Huang[MSFT]]

Hi Martin,

I will look into it and contact our product group to see if we could get
more information on it. I will post back as soon as possible.

Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Yan-Hong Huang[MSFT]]

Hello Martin,

I just got confirmation from our product group that this is a compiler
issue. It doesn't happen in Whidbey anymore because the explicit override
code underwent some changes.

The workaround is to Explicit implementation of "IInterfaceA.Content" in
ClassA avoids the compiler error, which you have found already.

Thanks very much for your feedback. If you have any more concerns on it,
please feel free to post here.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.