C++ inheritance not working correctly in VS2005 when C# is involved.

  • Thread starter Thread starter DrZogg
  • Start date Start date
D

DrZogg

It can't be... say it isn't so...

Yes.. there is a fly in the ointment

This bug requires 3 projects... yes this is a real world production
issue not some tinker toy thing.

Start with a C# interface assembly we will call Interfaces
namespace Interfaces
{
public interface ICqBase
{
void baseIt(); // does something
};

public interface ICqPolygonObject : ICqBase
{
void polygonObject(); // does something to polygons
};
public interface ICqStairObject : ICqPolygonObject
{
void stairObject(); // does something to stairs
};
}

Then assume you have a managed C++ assembly we will call TestLibrary
the oldClrSyntax switch is being used
its namespace looks as follows:
namespace TestLibrary
{
//
// This class is needed to reproduce the error.. I dont know why
//
public __gc class CqBase : public ICqBase
{
public: virtual void baseIt(void) { return; }
};
public __gc class CqPolygonObject : public CqBase, public
ICqPolygonObject
{
public: virtual void polygonObject() { return; }
};
}
So far this is very real world.. and everything works just fine.
Now lets assume we have another manged C++ assembly we will call
DerivedLibaray
the oldClrSyntax switch is being used also.
namespace DerivedLibaray
{
//
// All the problems are here with calling baseIt
//
public __gc class CqStairObject : public CqPolygonObject , public
ICqStairObject
{
public: virtual void stairObject() { this->baseIt(); return;
}
};
}
Notice we inherit from bother an inherited interface and a class with
inherited interfaces as well.
This shouldn't be a problem because Managed C++ inherits interfaces
virtually.
However the VS2005 compiler generates the folowing error
3>h:\data\code\testlibrary\derivedlibrary\DerivedLibrary.h(43) : error
C2385: ambiguous access of 'baseIt'
3> could be the 'baseIt' in base 'TestLibrary::CqPolygonObject'
3> or could be the 'baseIt' in base 'Interfaces::ICqStairObject'

Hmm thats odd... how is this ambigous.. you can't call baseIt in
ICqStairObject it's an interface?

Many change seem to make the problem go away.
Changing the interfaces to C++ fixes the issue.. except my interfaces
project has as over 200 interfaces.

removing the CqBase class fixes the issue but I really need this class
in my code because it has more than the baseIt method.

Moving the CqStair class to the TestLibrary from DerivedLibrary also
fixes things.
However, I have 76 projects for a reason. There are multiple products
and product version generated from the code and its just not feasible
to consolidate. Trust me on this one.

Converting the code to C++/CLI fixes the problem. I would use this
technique, if I didn't have 50 C++ projects with over 500,000 lines of
managed code using clrOldSyntax.

Anyone have any ideas for some other workaround.

This has been submitted to the VC team as a bug.

Thanks for the help

Christopher
 
Hello Christopher,
It can't be... say it isn't so...

Yes.. there is a fly in the ointment

This bug requires 3 projects... yes this is a real world production
issue not some tinker toy thing.

Start with a C# interface assembly we will call Interfaces
...
Click to expand...

I've reproduced the problem and got the "ambiguous access of 'baseIt'". To
resolve it I've called "baseIt" using fully qualified name:
"this->CqBase::baseIt();". This helped immediately.
 
I've reproduced the problem and got the "ambiguous access of 'baseIt'". To
resolve it I've called "baseIt" using fully qualified name:
"this->CqBase::baseIt();". This helped immediately.
Click to expand...


Vladimir ,

Thanks for the help.. and that does get things compiling right away.

However, doesn't this make the function non virtual?

By adding the scope resolution operator assumes you know what class has
the final derived implementation of the baseIt method. Isn't it
possible that the method will be overridden by another class?

For example; if someone where to derive from CqStairObject to create
say CqEscalator and needed to override baseIt ( for reasons other than
I can think of quickly ). Doesn't the scope resolution operator
you've added make things behave as non virtual?


Christopher
 
Okay,

Now I'm replying to myself...

This is the solution from Microsoft support
---- begin ----
This was a bug in VC++ 2003. The compiler should have never allowed
this code to compile. The root of the problem is that the C# name
lookup rules (and hence the CLR name lookup rules) specify that except
when name lookups start in an interface all interface members are
ignored. This means that the compiler should never find the baseIt
member in the interface. The problem is that this is contrary to how
ISO/IEC C++ specifies that name lookup should work and hence we did,
for a couple of releases, resist making this change. But with C++/CLI
we decided to bite the bullet and accept the C# name-lookup rules for
C++/CLI classes. We decided that we would only do this for C++/CLI we
would leave the Managed extension as they were. Unfortunately, as I
have said, it appears that there is a bug in Visual C++ 2003 in which
it appears to follow the C# name-lookup rules.

The best workaround I can see is to add a cast-node - for example:
public: virtual void stairObject() {
static_cast<CqPolygonObject*>(this)->baseIt(); return; }
and
CqStairObject* myStair = new CqStairObject();
static_cast<CqPolygonObject*>(myStair)->baseIt();
--- end ---

This does seem to solve the virtual issue because they are using a cast
instead of the scope resolution operator so you don't lose the virtual
nature of the function..
but it's very ugly.

So.. here is my next question...

IS MICROSOFT TRYING TO KILL C++ ?

The decision making on name lookup is nothing short of psychotic or
intentionaly trying to mess with C++ users.

In 2003 Managed C++ was contrary to the ISO spec when utilizing the NON
ISO keywords __interface
This sounds acceptiable to me because it makes things work in the
..NET enviorment where the ISO standard would break things.
Especially under the circumstances where __inteface is a Managed
extension not covered in the ISO spec.
In ISO C++ interfaces are just a concept not an implimentation.

In 2005 Microsoft decided to break old managed code ( which is being
used in VS2005 now as a compatibility bridge to C++/CLI) to favor the
ISO spec when using a NON ISO keyword (which in tern breaks compatibliy
with old Managed code ).
Did this decision come from someone who's next words were "****
our Managed C++ users" ( sorry ).

In 2005 C++/CLI ( which doesn't have any compatibility issues )
Microsoft decide to "bite the bullet" and not conform to the ISO
standard and revert to the C# spec again.
One only has to wonder if this will change this in the next
release to satisfy the ISO standard when using NON ISO keywords.

I'm really not sure how you could have more elegantly messed with C++
uses.

Sorry, its just very sad.. I've worked with VS since VS5 and I feel
very betrayed.

Christopher
 
IS MICROSOFT TRYING TO KILL C++ ?

In 2005 C++/CLI ( which doesn't have any compatibility issues )
Microsoft decide to "bite the bullet" and not conform to the ISO
standard and revert to the C# spec again.
One only has to wonder if this will change this in the next
release to satisfy the ISO standard when using NON ISO keywords.
Click to expand...

Microsoft is definitly not trying to kill C++.

When managed extensions was released, Microsoft got a lot of negative
feedback because the syntax was butt-ugly and confusing.

C++/CLI was designed to be comprehensible and easy to use.
IMO it is a lot better than managed extensions, but all the new keywords
make it non-ISO C++.
Since C++/CLI was designed specifically for working with .NET, it would make
sense to play by the .NET rules so that the behavior in 1 .NET language would
be similar to the behavior in other .NET languages.

This document is a good read if you are working with C++/CLI:
www.gotw.ca/publications/C++CLIRationale.pdf
it was written by Herb Sutter to explain the rational behind some of the
C++/CLI design decisions

C++ is alive and kicking, and will be so for a long time.

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno said:
Microsoft is definitly not trying to kill C++.

When managed extensions was released, Microsoft got a lot of negative
feedback because the syntax was butt-ugly and confusing.

C++/CLI was designed to be comprehensible and easy to use.
IMO it is a lot better than managed extensions, but all the new keywords
make it non-ISO C++.
Since C++/CLI was designed specifically for working with .NET, it would make
sense to play by the .NET rules so that the behavior in 1 .NET language would
be similar to the behavior in other .NET languages.
Click to expand...

This is acceptable to me. When you create a ref/value class in C++/CLI,
you aren't creating a C++ object, but a .Net object so there will be
differences in behaviour, and sometimes this difference may come at
compile time.

We're just in the process of evaluating the effort required to move our
projects from Borland C++Builder to C++/CLI with C# UIs, and so are used
to this sort of issue. Borland's VCL (very similar to the .net
librarys) is written in pascal, so even in C++, if you create a
derivation of TForm in C++, we get a pascal style object which behaves
differently in certain respects to a C++ object (when the vtable is
constructed is one big difference).

I think there has to be compromises when people want all this
functionality such as reflection and automatic garbage collection that
isn't available through standard C++.

Cheers

Russell
 
Okay guys,

So you think this C++/CLI stuff is the cat meow and proves Microsoft's
commitment to C++.

I tend to agree that the syntax is better than Managed C++.
It is definitely much similar to other .NET languages like C#.

However here is the business rub.

If I have a large investment in Managed C++ and VS2005 compiles it
almost as well as GCC or some other Unix compiler does, what does a
manager do?

1. Stay behind with VS2003 - no cost
2. Port from Managed C++ to C++/CLI - high cost
3. *Port from Managed C++ to C# - high cost

My guess is that most managers will opt for option number 3 (if there
are resources) not 2. Number 1 will be the option of companies pressed
for cash.

This is the big reason that I think C++ incompatibilities are going to
really mess with C++. C++/CLI may be great for someone just starting a
new .NET project. But if you have already been building a large C++
application you're now in a very dark hole.

And I sorry.. but its very clear that Microsoft's support for
clrOldSyntax in VS2005 just isn't there. I have experience porting
code and I made less changes moving windows C++ code to Unix with
Mainsoft's libraries than what I've done to get VS2003 C++ to compile
in VS2005.

The lack of compatibility between VS2003 and VS2005 for C++ is just a
subtitle but clear message to management of software vendors. The
message is this; if you want to keep developing in C++ we will happily
provide products for you that will mess with you're business.

However, I haven't had to make a single change to a C# module while
moving from VS2003 to VS2005 and the message is very clear, if you're
making business decisions.


Sorry,


Christopher
 
DrZogg said:
Okay guys,

So you think this C++/CLI stuff is the cat meow and proves Microsoft's
commitment to C++.
Click to expand...

I didn't say that at all. My point was that when you create a 'ref
class' in C++/CLI, you must expect some differences either at runtime,
compile time (as in this case), or both, compared to a 'class' object.

Cheers

Russell
 
If I have a large investment in Managed C++ and VS2005 compiles it
almost as well as GCC or some other Unix compiler does, what does a
manager do?
Click to expand...

GCC or whatever does not compile managed extensions at all.
1. Stay behind with VS2003 - no cost
2. Port from Managed C++ to C++/CLI - high cost
3. *Port from Managed C++ to C# - high cost

My guess is that most managers will opt for option number 3 (if there
are resources) not 2. Number 1 will be the option of companies pressed
for cash.
Click to expand...

I know several companies that are still developing in VS2003 and even some
that require VC6.
this has not so much to do with money, as with 'if it ain't broken, don't
fix it'
This is the big reason that I think C++ incompatibilities are going to
really mess with C++. C++/CLI may be great for someone just starting a
new .NET project. But if you have already been building a large C++
application you're now in a very dark hole.

And I sorry.. but its very clear that Microsoft's support for
clrOldSyntax in VS2005 just isn't there. I have experience porting
code and I made less changes moving windows C++ code to Unix with
Mainsoft's libraries than what I've done to get VS2003 C++ to compile
in VS2005.
Click to expand...

It depends. I have helped some people port medium size projects to VC2005
via clrOldsyntax.
sure, they needed some tweaking and small changes (the projects, not the
people) but on the whole
the process was fairly painless.
The lack of compatibility between VS2003 and VS2005 for C++ is just a
subtitle but clear message to management of software vendors. The
message is this; if you want to keep developing in C++ we will happily
provide products for you that will mess with you're business.
Click to expand...

Microsoft told developers very early on that managed extensions was not
future proof, and that
a much more natural syntax was in development. C++/CLI is meant to stay.
it's not as if this came out of the blue.
However, I haven't had to make a single change to a C# module while
moving from VS2003 to VS2005 and the message is very clear, if you're
making business decisions.
Click to expand...

C# was developed specifically for .NET, so it makes sense that they get it
right the first time.

As for business decisions, it all depends on the goal, infrastructure and
other considerations.
I personally prefer C# for .NET class libraries and applications unless I
have to do something where C++/CLI has an advantage, like reusing existing
code or interoperability with unmanaged software.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
So.. Microsoft still insist this isn't a bug and here is my response.

----------------------------------------------------------------------------------------------------

I believe that the responding technician doesn't fully understand the
problem as reported.

A. ISO/IEC C++ doesn't define an __interface keyword so how could name
lookup for an interfaces (a Microsoft Managed extension to ISO/IEC C++)
be contrary to the ISO/IEC standard?

B. The error in the code requires that two C++ assemblies be involved.
If the CqStairObject class is moved to the middle assembly then
everything compiles just fine (Please note that a commented example of
this is included in TestLibrary.zip). So this BUG involves there being
more than one managed C++ assembly not simply a difference in the
lookup technique the compiler is using. If this was the case you would
see this error on a much more consistent basis.

C. The proposed work around is very expensive and very difficult to
explain when it should be applied, due to the inconsistent nature of
this bug.


Christopher
 
Back
Top