Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: For Philosophers and Lawyers Message-ID: <72535@microsoft.UUCP> Date: 23 May 91 20:35:26 GMT References: <519f23cc.19260@apollo.HP.COM> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 25 In article purtill@morley.rutgers.edu (Mark Purtill) writes: |williams_j@apollo.HP.COM (Jim Williams) writes: |>class A; |>class B; |>B* f(A* ap) {return (B*)ap;} | |>The compiler accepts the above code with no problems. But how can the complier |>cast an A pointer to a B pointer? The compiler doesn't know anything (yet) |>about A or B. Is A derived from B? Is B derived from A? If B is virtually |>derived from A, the cast in f() is illegal, but the compiler, not knowing if |>B is virtually derived from A, signals no error. Does this make sense? .... C++ allows these unsafe casts so that programmers can use pointers to objects without always having to include class declarations. As long as a class doesn't actually do anything with the object pointed-at, the class declaration may not be needed. Virtual bases and MI break these bitwise-equivalent casts, but on the other hand, I don't think you'd want to make C programs or C++ programs only using SI pay the penalty for supporting MI and virtual bases. Mark's suggestions are similar to discussions on comp.std.c++ about support for dynamic type information. Interested readers may wish to review the discussions there.