Newsgroups: comp.std.c++ Path: utzoo!utgpu!craig From: craig@gpu.utcs.utoronto.ca (Craig Hubley) Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <1991Mar3.004313.17674@gpu.utcs.utoronto.ca> Organization: UTCS Public Access References: <27C95D3A.1715@tct.uucp> <1991Feb27.154311.782@csc.ti.com> <27CD159D.6581@tct.uucp> Date: Sun, 3 Mar 1991 00:43:13 GMT In article <27CD159D.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to peterson@choctaw.csc.ti.com (Bob Peterson): >>In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>>Presumably, a well-designed class hierarchy will use a virtual >>>function to store objects ... >> >>Researchers and vendors have taken a number of implementation approaches >>... The details of the various implementations vary widely, but few depend >>on virtual functions to supply type information. > >Is there any reason to avoid virtual functions for object storage? The need to derive all "storable" types from a given base. Among other problems, you can't store an int or a char* that way. If you are using a single base class library, you can define store() and retrieve() in that base. But this is not flexible enough for most OODBs. A more common approach is to define keywords like "persistent" that can be applied to any object. This requires preprocessing outside the definition of C++. >I had not envisioned a virtual function to return type information, >but rather a virtual function to actually _do_the_work_, so no one >outside of that function need know the actual type of the object >stored. This works so long as you are prepared to write a new function for each storable type. This is not what I expect from an OODB. -- Craig Hubley "...get rid of a man as soon as he thinks himself an expert." Craig Hubley & Associates------------------------------------Henry Ford Sr. craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig