From 8591627265111430849 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,206db806b836bf67 X-Google-Attributes: gidf78e5,public From: "Bradd W. Szonye" Subject: Re: Pointers to incomplete type Date: 1998/01/23 Message-ID: <6a7fli$gtj@examiner.concentric.net>#1/1 X-Deja-AN: 318762519 References: <69osom$jf3@examiner.concentric.net> <6a0a4g$rf1@shell.magma.ca> <6a0t54$k83@examiner.concentric.net> <6a3be4$6qu$1@uuneo.neosoft.com> X-Original-Date: Thu, 22 Jan 1998 07:53:56 -0500 Originator: austern@isolde.mti.sgi.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: Concentric Internet Services X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNMlfc0y4NqrwXLNJAQFcPQH+JITlkIHdeRMr2rz/MlDtZVb30qCyF+zW VbVUyjoA5FejJnJ7zX9znPqBjEPSkmY/Um5pxtMjTxwuZhqW4GaAaw== =9XKe Newsgroups: comp.std.c++ Bill Wade wrote in message <6a3be4$6qu$1@uuneo.neosoft.com>... > >You've listed a number of ... reasons [for putting vptrs in pointers]. >I'll take the opposite side. [The alternate model does not handle the case of assigning 'this' to a variable outside the object very well.] I've given this some more thought, and re-phrased the two sides of this debate. My original hypothesis: S1. Polymorphism is irrelevant or trivial when an object's type is statically known. S2. Polymorphism is important when an object is accessed by reference. S3. Additional information can be stored in references/pointers to polymorphic types without impacting references/pointers to non-polymorphic type with sufficient optimizer intelligence (still unproved, and the subject of this thread). Therefore, H. Type information (eg, vptrs) should appear in references/pointers, not among the object data, since that is where the information is necessary. Corollary: this can result in significant space savings, which is desirable. Mr. Wade's counter: W1. During construction, an object's static type changes. W2. It is possible to assign 'this' to pointers outside the object during construction. Therefore, C. The implementation must be able to adjust the type of 'p' where the assignment 'p = this' occurs during construction of a base class. I must agree that statement C is a valid criticism of my hypothesis, H. There are only a few valid ways to cope with the 'p = this' problem; the ones obvious to me either involve tracking 'this' and changing it everywhere or associating the type with the object itself, which negates the benefits of my alternate object model. Neither is particularly satisfactory. One solution, using handles for pointers, leads to some other nice effects, like simplifying automatic memory management and memory reallocation, but it certainly does not improve speed or space performance. So I'll concede that my alternate model may not be viable from a performance standpoint--unless somebody more innovative than I can address the problem of statement C. This leads me to ask another question: I've heard that the traditional cfront vptr-in-object memory model is not the only possible choice for C++, but what are some alternatives with comparable performance? Finally, it occurred to me that there still are some optimizations of the vptr-in-object model which may be viable. For example, consider another implementation with 32-bit vptrs. The optimizer could determine that an entire inheritance hierarchy has fewer than 256 classes and that each class in the hierarchy has byte alignment; it then can replace the 32-bit vptr with an 8-bit index into a 256-element vtbl array. This handles the hierarchy of lightweight character objects (in my earlier article) fairly well, probably better than either vptr-in-object or vptr-in-reference. Of course, the space advantange of this might be nullified by the performance disadvantage of using 8-bit indices on a particular platform. I think I would call this alternate-alternate model the 'vidx-in-object' model, where 'vidx' means "virtual table index" instead of the more common "virtual table pointer." I'd call it the 'vi' model, but then I might confuse "virtual index" with my favorite editor. (Okay, second favorite, but I don't have authority to install vim everywhere I work.) --- Bradd W. Szonye bradds@concentric.net http://www.concentric.net/~Bradds --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]