[llvm-commits] [dragonegg] r150341 - in /dragonegg/trunk: include/dragonegg/ABI.h src/DefaultABI.cpp

[Bill Wendling]

On Feb 13, 2012, at 4:16 PM, Bill Wendling <wendling at apple.com> wrote:

> On Feb 13, 2012, at 1:05 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On Feb 13, 2012, at 12:57 PM, Bill Wendling wrote:
>> 
>>> On Feb 12, 2012, at 9:13 PM, Chris Lattner <clattner at apple.com> wrote:
>>> 
>>>> On Feb 12, 2012, at 8:40 PM, Bill Wendling wrote:
>>>>>> Modified: dragonegg/trunk/include/dragonegg/ABI.h
>>>>>> URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/include/dragonegg/ABI.h?rev=150341&r1=150340&r2=150341&view=diff
>>>>>> ==============================================================================
>>>>>> --- dragonegg/trunk/include/dragonegg/ABI.h (original)
>>>>>> +++ dragonegg/trunk/include/dragonegg/ABI.h Sun Feb 12 09:35:35 2012
>>>>>> @@ -42,6 +42,7 @@
>>>>>> /// DefaultABIClient - This is a simple implementation of the ABI client
>>>>>> /// interface that can be subclassed.
>>>>>> struct DefaultABIClient {
>>>>>> +  virtual void anchor();
>>>>>> virtual ~DefaultABIClient() {}
>>>>> 
>>>>> Why not just use the d'tor as the anchor instead of a whole other (unused) method?
>>>> 
>>>> That actually slows down destruction of subclasses by preventing the virtual dtor from being inlined.  It probably doesn't matter in this case though :)
>>>> 
>>> True, but it's still a virtual call. :-) I mentioned it because there was already a lot of LLVM code which out-lines their d'tors for just this reason...
>> 
>> Dtor calls from derived class to base class dtors are not virtual, even if the dtor is virtual.  Think about what would happen if they were.
>> 
> Communism?
> 
Snarkiness aside, I know that d'tors can be inlined and all. But in several places the subclasses' d'tors are defined in the same file as the base class's d'tor. So it can inline just fine.

Anyway, I'm not adamant that the d'tor should be the anchor. Just wanted to point out a possible different approach that I've seen in several places in LLVM. :)

-bw