From owner-freebsd-hackers  Mon Mar 17 09:54:48 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA22845
          for hackers-outgoing; Mon, 17 Mar 1997 09:54:48 -0800 (PST)
Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA22840
          for <hackers@freebsd.org>; Mon, 17 Mar 1997 09:54:41 -0800 (PST)
Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id ma001260 for <hackers@freebsd.org>; Sun, 16 Mar 1997 10:16:10 +0000
Message-ID: <332BC869.37B7@wgold.demon.co.uk>
Date: Sun, 16 Mar 1997 10:16:09 +0000
From: James Mansion <james@wgold.demon.co.uk>
Organization: Westongold Ltd
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: hackers@freebsd.org
Subject: Re: Barb problem, FOUND
References: <199703160612.XAA13150@rover.village.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In no way shape or form is an inline virtual function (destructor or
not) 'dunious'.  Its quite legal.  (Whether you might consider it to be
bad style is another matter.  You can't always avoid it if the class is
a template, though that's clearly not the case with tvision)

Bear in mind that smart C++ systems will merge duplicated static emitted
inlines whether they are emitted as a result of too much complexity or
through being vritual.

Further, such 'outlined' virtuals need only be emitted in the module
chosen to carry the vtable, and will only potentially bloat if there is
no convenient method to tag the vtable to.

If the compiler cannot handle code like this, then the compiler should
be fixed.

James

Warner Losh wrote:
> 
> {standard input}: Assembler messages:
> {standard input}:1147: Warning: GOT relocation burb: `__vt$5TNode' should be global
> 
> OK.  The problem here is trivial to reproduce.
> 
> All of the members of TNode are virtual.  Even the dtor, and it is
> specifically inline (which is a major no-no for virtual dtors (and
> virtual functions in general) because most compiler give multiple
> copies).
> 
> This message should really read
> 
> "TNode::~TNode is an inline virtual function, and I don't know how to
>  cope, so fix the dubious construct in the code, OK"
> 
> In the case of tvision 0.3, I see it for each of the classes that have
> virtual inline functions, but it reports the wrong function name.
> 
> Comments?
> 
> Warner