inner member classes in final outer class

Regan Heath regan at netmail.co.nz
Sun Sep 16 13:17:36 PDT 2007


Bruno Medeiros wrote:
> Regan Heath wrote:
>> Bruno Medeiros wrote:
>>> Regan Heath wrote:
>>>> Kirk McDonald wrote:
>>>>> coxalan wrote:
>>>>>> Frits van Bommel Wrote:
>>>>>>
>>>>>>
>>>>>>> I just looked it up; from the documentation (the page you linked
>>>>>>> above): ===== Non-static nested classes work by containing an extra
>>>>>>> hidden member (called the context pointer) that is the frame
>>>>>>> pointer of the enclosing function if it is nested inside a
>>>>>>> function, or the this of the enclosing class's instance if it is
>>>>>>> nested inside a class. =====
>>>>>>>
>>>>>>> In the code above the class is nested in another class (not a
>>>>>>> function), so the context pointer is the 'this' of the enclosing
>>>>>>> class, i.e. a copy of 'o'.
>>>>>>
>>>>>>
>>>>>> Yes, the "this" of the outer class is stored in each inner member
>>>>>> class. So on a 32 bit machine: Each inner class contains 4 extra
>>>>>> bytes storing the address of the outer class (This is what I meant by
>>>>>> using the term "pointer": An address is stored.)
>>>>>>
>>>>>> In my code example, the outer class 'o' is final. That means that the
>>>>>> reference stored in 'o' will never change, so for all instances of
>>>>>> 'o.Inner' the address stored in the context pointer will be the same.
>>>>>> This is redundant, and I wonder if the optimization could be done to
>>>>>> _not_ store the reference pointers for instances of member classes of
>>>>>> final outer classes.
>>>>>
>>>>> That o is final is irrelevant. Consider:
>>>>>
>>>>> Outer.Inner foo() {
>>>>>     final Outer o = new Outer;
>>>>>     return o.new Inner;
>>>>> }
>>>>>
>>>>> The lifetime of the instance of the Inner class can easily exceed 
>>>>> that of the original reference to the instance of the Outer class 
>>>>> which created it. Therefore, the Inner class must have its own 
>>>>> reference to the Outer class.
>>>>
>>>> Must it?  What if the inner classes had a static reference to the 
>>>> outer?
>>>> eg.
>>>>
>>>> class Outer
>>>> {
>>>>   class Inner
>>>>   {
>>>>     static Outer outer; //only one copy for all instances of Inner
>>>>   }
>>>> }
>>>>
>>>> So, if you have X instances of Outer, creating Y instances of Inner 
>>>> you will have only X outer references, instead of X*Y outer references.
>>>>
>>>
>>> That's wrong. You don't have X outer references, there is only one 
>>> instance of outer (aka Outer.Inner.outer). A static attribute in a 
>>> member declaration makes it unique, even if the member is an inner 
>>> class.
>>
>> One of us is missunderstanding something :)
>>
>>
>> I was describing this case:
>>
>> class Outer
>> {
>>   class Inner
>>   {
>>   }
>> }
>>
> 
> Describing that case where? Your most recent post was this:

I was describing the OP's problem case, granted I did so following my 
example solution case which was perhaps confusing.

>  >>> Must it?  What if the inner classes had a static reference to the 
> outer?
>  >>> eg.
>  >>>
>  >>> class Outer
>  >>> {
>  >>>   class Inner
>  >>>   {
>  >>>     static Outer outer; //only one copy for all instances of Inner
>  >>>   }
>  >>> }
>  >>>
>  >>> So, if you have X instances of Outer, creating Y instances of Inner
>  >>> you will have only X outer references, instead of X*Y outer 
> references.
> 
> Which I interpret as describing this case:
 >
>   class Outer
>   {
>     class Inner
>     {
>       static Outer outer; //only one copy for all instances of Inner
>     }
>   }
> 
> .... which is the one I was commenting on my reply ... :/ ?

Well, that's where you're confused (by my badly constructed post).

I was describing the OP's problem case, the current D behaviour (unless 
I'm mistaken) which is for every instance of the inner class to have a 
context pointer.

The example above using static was my suggested solution, of sorts.

Regan



More information about the Digitalmars-d mailing list