Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.lang.c++ Subject: Re: asking an object for its type Message-ID: <27C6E04D.2914@tct.uucp> Date: 23 Feb 91 21:36:13 GMT References: <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <27C2D580.3B49@tct.uucp> <1991Feb22.194649.13381@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 55 According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27C2D580.3B49@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>"More intelligent"? Your prejudices are showing. :-) > >Other languages support a syntax with fewer seams, and resolve efficiency >issues with an optimizer. C++ deliberately doesn't do this and leaves >it in the hands of the programmer, therefore C++ as a language decides that >it will be less intelligent and force programmers to be more intelligent. Ah, that kind of intelligence. I had understood it to mean "the choice of an intelligent programmer," which is of course quite a different implication. >>C++ is statically typed. And there is no requirement that all classes >>be derived from a hypthetical Object class. So the features you desire >>cannot be accomplished in C++. > >Nonsense. There is absolutely no reason that the compiler cannot determine >that *circle* has a diameter at compile-time, indeed it MUST know that. Given -- at compile time, and the point in the source code where construction takes place. > x.has_member(diameter) can be completely optimized away at runtime where > the type is unambiguous ... I would contest the utility of the specific proposal of "has_member()" for C++. In C++, a member name does not sufficiently distinguish a class. Consider two subclasses of Object, called Circle and Planet. A circle's diameter is measured in pixels, a planet's in kilometers. If you know that a given Object "has_member(diameter)", do you have a Planet or a Circle, or perhaps something entirely different? To which type should you cast your Object*, to Planet* or Circle*? You cannot know for certain. The proposal for "has_member()" falls into the Objective-C/Smalltalk "all messages [and member functions] are alike" trap, along with its characteristic weak point of encouraging a global mapping of name to magic number, which causes complications for separate compilation, especially for pre-compiled libraries. >>I pay only for those OOP features I need, and no more. > >Nobody is suggesting a compromise to this principle. I disagree. The proposed "has_member()" function would require me to pay the cost of a virtual function table for each and every object that may someday be used as a base class, since the compiler cannot predict whether I or some other programmer will test for members of that class or its derived classes. The same argument applies to any dynamic "this is my _real_ type" information kept by the compiler. -- 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)