From -5641257427481660860
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,206db806b836bf67
X-Google-Attributes: gidf78e5,public
From: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Subject: Re: Pointers to incomplete type
Date: 1998/02/02
Message-ID: <34D61B7A.7987B954@physik.tu-muenchen.de>#1/1
X-Deja-AN: 321470823
X-Nntp-Posting-Host: coulomb.t30.physik.tu-muenchen.de
Content-Transfer-Encoding: 7bit
References: <69osom$jf3@examiner.concentric.net><6a0a4g$rf1@shell.magma.ca><6a0t54$k83@examiner.concentric.net><6a3be4$6qu$1@uuneo.neosoft.com><6a7fli$gtj@examiner.concentric.net> <6aisf1$n8s$1@uuneo.neosoft.com> <6ajsuq$108@examiner.concentric.net>
X-UID: 0000000001
X-Status: $$$$
Content-Type: text/plain; charset=us-ascii
Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Mime-Version: 1.0
Newsgroups: comp.std.c++
Originator: clamage@taumet


Bradd W. Szonye wrote:
> 
> Bill Wade wrote in message <6aisf1$n8s$1@uuneo.neosoft.com>...
> >
> >If you just want smaller impact in the objects, make all pointers contain
> >the vtable for the fully constructed, most derived object.  In the objects,
> >use a single bit to indicate if it is fully constructed.  For partially
> >constructed object use some other means (an expensive global mapping from
> >pointers to current dynamic type) for dynamic type resolution.
> >
> >You could also have a slightly different language where even for partially
> >constructed objects, virtual dispatch occurred using the fully constructed
> >object's methods.
> 
> [Briefly: you're right about the vidx model not playing well with sl's.]
> 
> I wouldn't want that! If that were acceptable, I wouldn't worry so much
> about the model being conforming. However, you did (indirectly) give me an
> idea! The big clue was "use an expensive mapping" for the tricky case.
> 
> You might not be able to find a spare bit in the object, but you can do
> something else. Instead of setting the global pointer to the most derived
> class, give it a trap representation. Use some sort of snap technique (like
> float emulation) to adjust the vptrs when used. I guess you'd still have to
> store the "real" vptr somewhere (thereby losing at least some of the space
> savings for this class), but then I don't expect that a lot of polymorphic
> classes are handing out their this pointers during construction.
> 
> Thanks for the tip!

Another idea:

As the size of the object usually matters only for arrays, you could
set up the rule that the vptr is always stored in front of the array
the object belongs to (single objects would be treated as one-element
arrays for this purpose). Then you need a way to decide if your object
is the first one in the array. This could be done in two ways (plus
those I don't see now ;-)):

- allocate one extra char for the object (this may cause the same
  space consumption as a vptr for pointer-aligned classes, but may
  be much less for char-aligned classes). A flag would in principle
  be sufficient, but a faster implementation would be to store the
  number of objects to skip, or 255, if it's at least 255 objects
  (that is, if you encounter '255', you must look again after going
  so far).
- store this information in the pointers (in this case, a flag is not
  enough, instead the index or offset has to be stored; OTOH this also
  allows easy range checking support in debugging versions).

This solution could have another size advantage: If you store the size
of dynamic objects in the vtbl, you can replace the size value of the
memory block by the vptr (if your vtbls are all aligned at an even
number
of bytes, and allocation is in even sizes as well, you can use the
lowest bit to decide if it is a size or a vptr, by setting it to 1
for size, as vptrs are more often accessed). This way, the vptr
itself wouldn't occupy any space at all. Of course, if there is an
user supplied operator new, you cannot assume anything about memory
layout, so you have to allocate extra memory for the vptr again.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]