Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / December 2003

Tip: Looking for answers? Try searching our database.

Explicit interface implementation compiler bug in VS 2003?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Martin Zenkel - 03 Dec 2003 08:48 GMT
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] - 04 Dec 2003 02:56 GMT
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

Signature

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

--------------------
Martin Zenkel - 04 Dec 2003 06:39 GMT
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] - 04 Dec 2003 09:41 GMT
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

Signature

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

--------------------
Martin Zenkel - 04 Dec 2003 11:48 GMT
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] - 05 Dec 2003 09:28 GMT
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

Signature

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

--------------------
Martin Zenkel - 09 Dec 2003 11:20 GMT
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
Yan-Hong Huang[MSFT] - 10 Dec 2003 09:19 GMT
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] - 11 Dec 2003 05:33 GMT
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.
Gary Chang [MSFT] - 09 Dec 2003 07:29 GMT
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

Signature

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

--------------------
Martin Zenkel - 09 Dec 2003 11:22 GMT
Hi Gary,

>I have test your sample code in the current Whidbey Beta

Thank you very much.

Best regards, Martin Zenkel

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.