Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!garcon!garcon.cso.uiuc.edu!grunwald
From: grunwald@flute.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Multiple inclusion of virtual tables...
Message-ID: <GRUNWALD.89Mar24164036@flute.cs.uiuc.edu>
Date: 24 Mar 89 22:40:36 GMT
References: <GRUNWALD.89Mar17220936@flute.cs.uiuc.edu> <340@spinifex.eecs.unsw.oz>
Sender: news@garcon.cso.uiuc.edu
Organization: University of Illinois, Urbana-Champaign
Lines: 41
In-reply-to: malcolmp@spinifex.eecs.unsw.oz's message of 23 Mar 89 01:08:12 GMT

In article <340@spinifex.eecs.unsw.oz> malcolmp@spinifex.eecs.unsw.oz (Malcolm Purvis) writes:
....	
	   Couldn't you change the compiler to do the equivalent of +e<name>
   automatically so you wouldn't have these problems?  You could put in rules
   that say if when compiling a file it finds a constructor/destructor for a

Yes, as others have noted, this would work. The more general solution is to
pick some arbitrary function as the ``anchor'' for the vtbl & virtual inlines.
I don't know if this would be more suitable or not. I think this might be a
better way to do it.

	(inline virtual functions? How strange)

Not that strange. Consider the Priority Queue classes in libg++. The
root class (call it PQ) defines the interface for subclasses using
virtual functions. Now consider subclass ``PairPQ'' and ``SplayPQ''.
If I do:
		SplayPQ pq;
		pq.enq(.....)

then I *know* that i'm calling ``SplayPQ::enq''. By that same light, If I say:
		SplayPQ *pq = new SplayPQ
		pq -> enq(.....)

I still know which enq I'm talking about, but if I say:
		SplayPQ *pq = someOtherFunction();
		pq -> enq(....)

I no longer know the enq routing to use, so I must use the virtual function,
unless I can determine something about ``someOtherFunction()''.

In the first two cases, you get the generality of virtual functions and
class hierarchies without always having to pay the cost if you're using
a specific instance of a class lattice. This can be very important in
very performance constrained implementations.


--
Dirk Grunwald
Univ. of Illinois
grunwald@flute.cs.uiuc.edu