Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!tilde.csc.ti.com!choctaw!peterson From: peterson@choctaw.csc.ti.com (Bob Peterson) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <1991Feb27.154311.782@csc.ti.com> Date: 27 Feb 91 15:43:11 GMT References: <27C2D973.3C1B@tct.uucp> <27C95D3A.1715@tct.uucp> Sender: usenet@csc.ti.com (USENET News System) Organization: TI Computer Science Center, Dallas Lines: 36 Nntp-Posting-Host: choctaw In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to dsouza@optima.cad.mcc.com (Desmond Dsouza): >... >>1. Persistent objects: When reading in one of these from disk, you >> need to know what constructor to call. Hence you need to encode in >> the persistent image the ClassId of the object. > >Presumably, a well-designed class hierarchy will use a virtual >function to store objects; and a virtual function by definition will >already know the exact type of the object it is storing. > This view of how to implement persistence seems narrow. Researchers and vendors have taken a number of implementation approaches, including the one you mention. The details of the various implementations vary widely, but few depend on virtual functions to supply type information. In all cases some indication of the actual type of the stored object must be available when the object is recovered. Of course, this implies type information must be available when an object is to be stored. I daresay many of us working in the area of persistence would welcome a standard way of encoding and accessing type information. Actually the problem generalizes quite readily to exporting and importing an object from and to an address space, regardless of the purpose. An obvious purpose, other than storage, is for interprocess communications. >... >-- >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) Bob Peterson Compuserve: 70235,326 Expressway Site, Texas Instruments Internet: peterson@csc.ti.com North Building, P.O. Box 655474, MS238 Landline: (214) 995-6080 2nd Floor, Dallas, Texas, USA 75265 CSC Aisle C3