From 788204283294623711 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-25 08:32:50 PST Newsgroups: comp.std.c++ Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) Subject: Re: Zero-length structures and pointer comparisons Message-ID: <9236103.3697@mulga.cs.mu.OZ.AU> Sender: news@cs.mu.OZ.AU Organization: Computer Science, University of Melbourne, Australia References: <9235622.25587@mulga.cs.mu.OZ.AU> <5458@holden.lulea.trab.se> Date: Fri, 25 Dec 1992 16:26:43 GMT Lines: 78 jbn@lulea.trab.se (Johan Bengtsson) writes: >Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU) wrote: >: jbn@lulea.trab.se (Johan Bengtsson) writes: > >: >Markku Sakkinen (sakkinen@jyu.fi) wrote: >: >: BTW, actually total order is >: >: a simple thing within an OODB _because_ the identity of each object >: >: is assured not to change. >: > >: >It would impose severe restrictions on how the virtual address space >: >could be used though. The OODBMS may end up in a situation where >: >it can't get a persistent object into memory, not because it has used up >: >all virtual memory addresses, but because all unused virtual memory >: >adresses would violate the total ordering property. > >: I thought that the idea was that for OODBMSs, you DON'T compare virtual >: addresses for pointers to persistent objects, instead you compare the object >: ids. Maybe someone could explain the problems in a little more detail? > >As Stuart MacMartin said, if the OODBMs uses objects of class Handle >(never mind the name) to represent references to persistent objects >you will need to have > >ptrcmp(Handle,Handle), if you want templates to compare Handles the >same way they compare pointers. The OODBMs should provide that. >Also it should provide ptrcmp(Handle,void*) and ptrcmp(void*,Handle). Actually, I don't think that these last two are necessary (see below). >_Some_ OODBMs use void* as their Handles (they play tricks by >using virtual memory mapping to persistent storage), so they must >provide a ptrcmp(void*,void*) that can tell the difference between >pointers to persistent objects and normal memory pointers. For persistent >objects, it then finds the object ids and makes the comparison. > >My point is that this may be difficult, or slow (although I don't >really have any data on that). The alternative is to simply compare >the void pointers, even for pointers to persistent objects, however >that imposes the unacceptable restrictions I described in my previous >posting. For these OODBMSs, (void *) == (void *) will be implemented simply by comparing the void pointers. The statement in the ARM that "two pointers to the same object compare equal" will NOT always hold. (As you have been arguing, to implement == with this guarantee would be too difficult and too inefficient). Since these systems aren't going to be standard-compliant anyway, unless we change the standard, I don't really know what we can conclude from them with regard to ptrcmp(). >A more difficult issue is what do you do if there is more than one >OODBMs in use, or more realistically, one OODBM, and one distributed >object manager (that similarly uses Handles to distributable objects). >Who is responsible for providing the needed ptrcmp(OODB_Handle,Distr_Handle) >and ptrcmp(Distr_Handle,OODB_Handle) functions? This may become >totally unmanageable if handle-based schemes become common. The template classes are always going to be comparing objects of the same type. If you have a collection of OODB_Handles, then use ptrcmp(OODB_Handle, OODB_Handle). If you have a collection of Distr_Handles, then use ptrcmp(Distr_Handle, Distr_Handle). If you have a collection that you want to use to store both Distr_Handles and OODB_Handles, then you will have to write your own type-safe union class Any_Handle anyway, and then *you* are going to be the one who will implement ptrcmp(Any_Handle, Any_Handle). There is no need for ptrcmp(Distr_Handle, OODB_Handle). >Hope this is a little bit clearer. Quite a bit clearer. Thanks! -- Fergus Henderson fjh@munta.cs.mu.OZ.AU This .signature virus is a self-referential statement that is true - but you will only be able to consistently believe it if you copy it to your own .signature file!