Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: Dynamic type loss considered harmless Message-ID: <27CD13B1.649B@tct.uucp> Date: 28 Feb 91 14:29:04 GMT References: <1991Feb19.051123.5198@gpu.utcs.utoronto.ca> <27C2D4B8.3AD3@tct.uucp> <1991Feb25.201923.14554@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 52 >>>There is no "cast to the dynamic type" operator ... >> >>That's a necessary result of the most basic type rules. > >Then why are Bjarne/Andy in favor of it ? At least so I've heard... I overstated my case. Let me try again: Adding dynamic type information would entail significant changes to the meaning of "type". Under current rules, a |Base| that is part of a |Derived| is indistinguishable from a plain |Base|. Inventing a distinction between them would require rethinking the type conversion rules, especially in view of multiple inheritance. >Dynamic type loss is OK if the type is not useful at runtime. However, >it can be useful in many more ways than deciding which version of its >predefined (and often unchangeable) functions to call at runtime. Granted, it can be useful, in the same sense that "goto" can be useful. As I've mentioned in another article, I've decided that I object, not so much to the proposed feature, but to the apparent attitude that the feature is almost indepensible. IMHO, it's not. >Those other uses can be supported without requiring every object to carry >a type tag through to runtime. I don't see how, unless you are referring to the optimization that objects without virtual function tables do not maintain a type tag. >As it stands, you cannot add any type- and context-specific functionality >to an object without access to its source code. This greatly restricts >reusability, to a level between that of say, Eiffel, and that of Ada. "Well, don't do that, then." If I can't modify the source code to a class, I may use use it, but I usually won't derive from it. >I do not consider this sufficient to support a components industry, as it >leaves too many ways for producing programmers to cut off options for those >building on their code. IMHO, any attempt to distribute binary-only C++ components intended for use _as_base_classes_ is probably doomed to failure in all but the simplest cases, for reasons that go far beyond the lack of dynamic typing. Adding a type tag won't solve the problems of non-virtual member functions and private (as opposed to protected) members. So C++ isn't a good language for binary components; so what? If I want Objective-C, I know where to find it. -- Chip Salzenberg at Teltronics/TCT , "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)