On Wed, 2008-01-23 at 14:46 -0500, Swaroop Sridhar wrote: > Manuel Fähndrich and Rustan Leino, ``Declaring and Checking Non-Null > Types in an Object-Oriented Language,'' Proc. 18th ACM Conference on > Object-Oriented Programming Systems, Languages, and Applications, > Anaheim, CA, October 2003. > http://research.microsoft.com/~maf/Papers/non-null.pdf
Their example on page 2 of how problems can arise is hopelessly borked. Note that m() is called from the A constructor using a this pointer of incorrect (because insufficiently initialized) type. This *ought* to be a static type error. The real error doesn't lie in the call to the overridden method m(). It lies in the fact that the implementation has updated the virtual dispatch table pointer prematurely. In a proper implementation, the virtual table pointer cannot be updated to point to B.vtable until all of the field initialization contracts have been met. If the update is delayed in this fashion, the illustrated problem evaporates. If the C# implementation/specification actually operates as described here, I conceded that it is memory safe, but I claim that it is not type safe from the application perspective. And yes, C# really does appear to work this way. See the discussion at: http://blogs.msdn.com/abhinaba/archive/2006/02/28/540357.aspx I guess what I'm saying is that this example doesn't really illustrate the point that they were trying to illustrate. It illustrates a much *bigger* problem in the method override system! And you can see signs that this is a problem in an awful lot of places. The general consensus in both C# and C++ is that calling any sort of virtual method from a constructor is a really bad idea. I understand the C# rationale. C# distinguishes initialization from construction, relegating construction to a post-initialization cleanup role that is (conveniently) no different from any other procedure call on the underlying data structure. I understand it, but I think it's amazingly icky. While the type system invariants are preserved, the application-level invariants most definitely are NOT preserved. YUCK! shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
