Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ucbvax!pasteur!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <11578@pasteur.Berkeley.EDU> Date: 1 Mar 91 20:38:41 GMT References: <27C95D3A.1715@tct.uucp> <1991Feb27.154311.782@csc.ti.com> <27CD159D.6581@tct.uucp> Sender: news@pasteur.Berkeley.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Lines: 23 In article <27CD159D.6581@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: |> 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. You're still missing the point, Chip. I'm generally against functions to return type information, but there are places where you need to do something of this type. Sure, you can have a virtual function to store an object on disk. But how are you going to read it back? There is nothing on the disk but data. A similar problem occurs when inter process communication is required. The system designer must provide some scheme to allow the type to be determined. The interesting thing, though, is that the solution many propose to the problem of determining the type doesn't address this situation at all! If, say, I provide an automatically generated virtual function to return the type somehow, that function won't tell me what's on the disk either. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck