Bug with 'dynamic_cast<>' in VC7.1

  • Thread starter Thread starter Hendrik Schober
  • Start date Start date
H

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
 
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
 
Carl Daniel said:
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.
Click to expand...

Thanks for checking Whidbey, I don't have
this here.
Can I consider this reported?
-cd
[...]
Click to expand...

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 said:
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.
Click to expand...

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
 
Carl Daniel said:
[...]
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
Click to expand...


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
 
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.
 
Vas said:
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.
Click to expand...

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.
Click to expand...

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
 
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.
 
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"
 
Vas said:
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.
Click to expand...

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
 
Vas said:
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
Click to expand...

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
 
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.
Click to expand...

Fortunatelly, it's no longer true.


B.
 
Back
Top