Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!husc6!genrad!charlie
From: charlie@genrad.com (Charlie D. Havener)
Newsgroups: comp.lang.c++
Subject: Re: VIRTUAL-NESS LOST  - A C++ mystery involving funcs returning objects not ptrs
Summary: Summary of E-mail responses
Keywords: virtual C++ overloaded operator interpreter
Message-ID: <33897@genrad.UUCP>
Date: 15 Mar 90 21:04:57 GMT
References: <33629@genrad.UUCP>
Sender: news@genrad.UUCP
Lines: 88


This is a summary of the three E-mail replies I received
about VIRTUAL-NESS LOST. The concensus is that the 'feature'
in cfront that keeps virtual-ness alive for a returned object
is not part of the C++ language definition. I suspected this.
I have been experimenting with returning pointers to Data
rather than the object, but even with a class specific overload
of the new operator, the expression interpreter takes twice as
long. Sigh....    Thank you for responding

// this seems to be what one must do in order to avoid
// garbage build up. I wish there was a more elegant/efficient solution.
Data *Plus::eval()  
    {
    Data *l;
    Data *r;
    Data *result;
    result =  (*(l = left->eval()) + *(r = right->eval())); 
    delete l;
    delete r;
    return result;
    }
----------------------------------------
Partial E-mail from:
Scott
sdm@cs.brown.edu

In article <33629@genrad.UUCP> you write:
> SYNOPSIS: If you return a derived class object from a
> function, can you then invoke a virtual function on it and 
> expect C++ to find the right one?
>
> Class Base { virtual print(); }
> Class Der : public Base { virtual print(); }
>
> Base func() { Der x; return x; }
>
> main()  { func().print(); }  // should it use the Base or Der print?
>	 	       // cfront uses Der print, Zortech 2.06 uses Base print
> if it was
> main()  { Base t; t = func(); t.print(); } // Clearly it should use the Base print
>
>I can find no definitive answer in any of my books or the
>C++ reference manual. Section 12.2 in the Ref manual about Temporary
>Objects comes close. It seems to say this might be implementation
>dependent. 

cfront is wrong, Zortech is right.  func() returns a Base, not a pointer to
a Base and not a reference to a Base, so functions called on the result of
func() will be statically bound.  Always.  More technically, the result of
func() is an object of type Base that is initialized with an object of type
Der.  Check the manuals under object initialization.

I ran across this same problem on the "other side" of the function call,
i.e., passing parameters into functions.  This was my posting:

> Article 5164 of comp.lang.c++:
> Subject: When polymorphic, when not?
> Date: 7 Dec 89 19:12:10 GMT
> 
---------------------------------------------------

Reply-To: mit-eddie!Sun.COM!tiemann

Virtualness is lost in GNU C++ as well.  I believe that GNU and
Zortech are right, and that cfront is wrong.

Michael
--------------------------------------------------

From mit-eddie!mcc.com!mit-eddie!@MCC.COM:vaughan%cadillac.cad.mcc.com Mon Mar 12 12:12:49 1990

When dealing with on object, rather than a reference or pointer to an
object, calls to function members are never "virtual".  The compiler
generally assumes that the object is exactly the type that it thinks
it is (it had to allocate space for it after all) and avoids the extra
overhead for looking them up in the virtual function table.  In your
example, the Base portion of the Der x object is copied and returned
as a Base object.  I would hope that the virtual function table
pointer is also made appropriate for a Base object.  Note that if this
were not the case, virtual functions redefined on Der that access
slots defined on Der but not on Base might be called.  Such slots
don't exist for the returned object.
-- 
 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan

-------------------------------------------------------