Bug with 'dynamic_cast<>' in VC7.1

[Hendrik Schober]

#include <iostream>

class B {
public:
virtual ~B() {}
};

class D : private B {
public:
B* getB() {return this;}
};

int main()
{
D d;
B* pb = d.getB();
D* pd = dynamic_cast<D*>(pb);
std::cout << pd;
return 0;
}

When running the above compiled with Comeau
or CW9, it emits '0' ('NULL'). With VC7.1 it
emits an address. I think that's a bug.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Carl Daniel [VC++ MVP]]

This sounds familiar enough to say that it might be a known bug (I might
even have reported it myself). In any case, the VC 2005 alpha exhibits the
same behavior as 7.1.

-cd

 

[Hendrik Schober]

This sounds familiar enough to say that it might be a known bug (I might
even have reported it myself). In any case, the VC 2005 alpha exhibits the
same behavior as 7.1.

Thanks for checking Whidbey, I don't have
this here.
Can I consider this reported?

-cd
[...]

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Carl Daniel [VC++ MVP]]

This sounds familiar enough to say that it might be a known bug (I
might even have reported it myself). In any case, the VC 2005 alpha
exhibits the same behavior as 7.1.

It looks like the dynamic_cast bug I reported earlier (in Everett) is a
different situation than this, so I'll file a bug report for this against
Whidbey.

-cd

 

[Hendrik Schober]

[...]
It looks like the dynamic_cast bug I reported earlier (in Everett) is a
different situation than this, so I'll file a bug report for this against
Whidbey.
Thanks!

-cd

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Guest]

I don't think it is a bug, the dynamic_cast doesn't allow accidental violation of the protection of private or protected base classes

Have a look at page 409 of Bjarne Stroustrup's book, it should return 0.

 

[Hendrik Schober]

I don't think it is a bug, the dynamic_cast doesn't allow accidental violation of the protection of private or protected base
classes.

However, VC7.1 allows it.
That's why I think it's a bug.

Have a look at page 409 of Bjarne Stroustrup's book, it should return 0.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Guest]

That might be the case, but you could also say that the compilers right and whatever documentation you've read is wrong. Derivation of protected and private are used for implementation details, while public derivation makes the derived class a subtype of the base. Theres a difference.

 

[Gabest]

If we are taking about this, here is another one, just a little bit
different. Instead of returning NULL, this one should return the pointer:

Found at http://gcc.gnu.org/ml/gcc-bugs/1999-11n/msg00556.html :

class Base
{
public:
virtual void f() {}
};

class Derived : public Base
{
};

class MoreDerived : protected Derived
{
public:
Base* as_base() { return this; }
};

int main()
{
MoreDerived md;
Base* bp(md.as_base());
if (dynamic_cast<Derived*>(bp))
puts("test succeeded");
else
puts("test failed");
}


vc71 outputs: "test failed"

 

[Carl Daniel [VC++ MVP]]

That might be the case, but you could also say that the compilers
right and whatever documentation you've read is wrong. Derivation of
protected and private are used for implementation details, while
public derivation makes the derived class a subtype of the base.
Theres a difference.

The difference is that the first bullet of paragraph 8 of section 5.2.7 of
the C++ standard specifically says that VC++ is wrong.

-cd

 

[Guest]

Sorry Hendrik, I read your question again, I didn't see the "emits" bit. My fault

I found a site, someone called Bruce Eckels. He pointed out that MS have said that they aren't building a compiler to follow the standard, its basically for building Windows apps. Fair enough I suppose

Heres the sit

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

 

[Carl Daniel [VC++ MVP]]

Sorry Hendrik, I read your question again, I didn't see the "emits"
bit. My fault.

I found a site, someone called Bruce Eckels. He pointed out that MS
have said that they aren't building a compiler to follow the
standard, its basically for building Windows apps. Fair enough I
suppose.

Heres the site

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

Unfortunately, his advice is both out of date and misleading.

VC6 predates the C++ standard. At the time of its release, VC6 was among
the most conformant compilers on the market. That was in 1998.

VC7 (aka VC++ .NET 2002) was released in 2002 and for that release the VC
team made very few standard conformance improvements and instead
concentrated on implementing .NET support in the C++ compiler along with
some backend features that had previously been released as the "Processor
Pack" for VC6. As a result, the conformance of VC7 is only marginally
better than that of VC6. The standard library shipped with VC7 is
significantly more conformant that that with VC6.

VC7.1 (aka VC++ .NET 2003) was primarily a standards conformance release,
making enormous improvements over VC6 and VC7 in this area.

Mr. Eckels final advice: "So the upshot is this: if you want to use
Microsoft C++, choose Managed C++ for .NET" is complete nonsense. Whether
you target Managed C++ for .NET or not is completely irrelevant. What he
should have said is "is you want to compile standard conformant code with
VC++, use the latest version (VC7.1)".

-cd

 

[Bronek Kozicki]

I found a site, someone called Bruce Eckels. He pointed out that
MS have said that they aren't building a compiler to follow the
standard, its basically for building Windows apps.

Fortunatelly, it's no longer true.


B.