www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inner member classes in final outer class

reply coxalan <coxalan web.de> writes:
Hello,

Consider this code:

class Outer {
    class Inner {
    }
}

void main() {
    final Outer o = new Outer;
    o.Inner i1 = o.new Inner;
    o.Inner i2 = o.new Inner;
    o.Inner i3 = o.new Inner;
}

According to http://www.digitalmars.com/d/class.html, each "o.Inner" instance
contains a "context pointer" to the enclosing outer class.

But in this case the enclosing outer class "o" is final, so in my opinion there
is no need to store the context pointer in i1, i2 and i3 again and again.
Instead, always the address stored in the reference "o" could be used.

Now two questions:

1) Would it be possible to have an optimization in the D compiler which removes
the context pointer in the case of final outer classes? Or will that result in
other problems I currently do not realize?

2) With the current dmd compiler, is there a way (maybe using template magic)
for a similar object design which circumvents the context pointer?

A suggestion was made here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58154
But the problem with that code is that I cannot have more than one outer class
of the same type possessing inner classes.

Thanks,

coxalan
Sep 15 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
coxalan wrote:

 Consider this code:
 
 class Outer {
     class Inner {
     }
 }
 
 void main() {
     final Outer o = new Outer;
     o.Inner i1 = o.new Inner;
     o.Inner i2 = o.new Inner;
     o.Inner i3 = o.new Inner;
 }
 
 According to http://www.digitalmars.com/d/class.html, each "o.Inner" instance
contains a "context pointer" to the enclosing outer class.
 
 But in this case the enclosing outer class "o" is final, so in my opinion
there is no need to store the context pointer in i1, i2 and i3 again and again.
Instead, always the address stored in the reference "o" could be used.



I'm pretty sure the context pointer is already a copy of 'o' (not a 
pointer to it as you seem to think).

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'.
Sep 15 2007
parent reply coxalan <coxalan web.de> writes:
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.
Sep 15 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 15 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
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.

The static reference will prevent the destruction of the outer when it 
leaves scope in your example above, but when will it be destroyed?  How 
does D currently deal with this in a normal "class contains static 
reference" situation?  Are these objects destroyed only at program exit?

I'm not sure I understand how static references or even normal members 
are implemented, are they implemented in the same was as global variables?

Should static outer references be the default behaviour?  It seems to be 
a neat little optimisation, assuming it doesn't cause destruction 
problems as described above and maybe even then.

The only case I can imagine wanting a seperate outer reference for each 
inner class is when I need to move inner classes from one outer to 
another, eg

auto o = new Outer;
auto p = new Outer;
auto i = new o.Inner;
i.outer = p;

I'm not sure this is even possible currently and I can't think of a 
reason why you might want to do this.

Regan
Sep 16 2007
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 16 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
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
   {
   }
}

where Inner automagically has an 'outer' member which refers to the 
Outer class instance.

Described here:
http://www.digitalmars.com/d/class.html

"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."

(NOTE: I'm not referring to the class definition I gave above which was 
a fictional representation of how D _could_ implement the context 
pointer as a static reference)

Then when I said "So, if you have X instances of Outer, creating Y 
instances of Inner" I meant _if_ you code something like this:

const int X = 10;
const int Y = 10;

for(int i = 0; i < X; i++)
{
   auto o = new Outer;
   for(int j = 0; j < Y; j++)
   {
     auto i = new o.Inner;
   }
}

You will have X (10) outer objects each with Y (10) inner objects, each 
containing a context pointer to the outer object, therefore you have X*Y 
(100) context pointers.  Making the context reference static would 
decrease this number to X (10) context pointers.

Make sense, or am I missunderstanding something?

Regan
Sep 16 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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:


 Must it?  What if the inner classes had a static reference to the 










 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 ... :/ ?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 16 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
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
Sep 16 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Regan Heath wrote:

 
 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



Ok, I know you were talking first about current D behavior, but I was 
talking about your suggested solution. You do understand why that 
solution wouldn't work as you expected?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 17 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I was 
 talking about your suggested solution. You do understand why that 
 solution wouldn't work as you expected?



Nope.

Are you referring to your comment:
"Removing the context pointer would imply having different, incompatible 
versions of the Inner class, and since that alters program semantics the 
compiler cannot do that"

?

Regan
Sep 17 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I was 
 talking about your suggested solution. You do understand why that 
 solution wouldn't work as you expected?



 Nope.
 
 Are you referring to your comment:
 "Removing the context pointer would imply having different, incompatible 
 versions of the Inner class, and since that alters program semantics the 
 compiler cannot do that"
 
 ?
 
 Regan



No, I mean making the context pointer static.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 17 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I was 
 talking about your suggested solution. You do understand why that 
 solution wouldn't work as you expected?



 Nope.

 Are you referring to your comment:
 "Removing the context pointer would imply having different, 
 incompatible versions of the Inner class, and since that alters 
 program semantics the compiler cannot do that"

 ?

 Regan



 No, I mean making the context pointer static.



Please explain why it wont work (as I expect - assuming you're not 
confused about what I expect too <g>)?

Regan
Sep 17 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I 
 was talking about your suggested solution. You do understand why 
 that solution wouldn't work as you expected?



 Nope.

 Are you referring to your comment:
 "Removing the context pointer would imply having different, 
 incompatible versions of the Inner class, and since that alters 
 program semantics the compiler cannot do that"

 ?

 Regan



 No, I mean making the context pointer static.



 Please explain why it wont work (as I expect - assuming you're not 
 confused about what I expect too <g>)?
 
 Regan



Damn it, I already did! :P
You said you wanted to "have only X outer references, instead of X*Y 
outer references", right? And like I said, if you (or the compiler) made 
the context pointer static (as in 'static' storage class in a var 
declaration), you would have only 1 outer reference (not X), since 
static would make that "variable" unique.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 17 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I 
 was talking about your suggested solution. You do understand why 
 that solution wouldn't work as you expected?



 Nope.

 Are you referring to your comment:
 "Removing the context pointer would imply having different, 
 incompatible versions of the Inner class, and since that alters 
 program semantics the compiler cannot do that"

 ?

 Regan



 No, I mean making the context pointer static.



 Please explain why it wont work (as I expect - assuming you're not 
 confused about what I expect too <g>)?

 Regan



 Damn it, I already did! :P
 You said you wanted to "have only X outer references, instead of X*Y 
 outer references", right? And like I said, if you (or the compiler) made 
 the context pointer static (as in 'static' storage class in a var 
 declaration), you would have only 1 outer reference (not X), since 
 static would make that "variable" unique.



Doh!  Somehow I totally missed that, you're quite correct. :)

Regan
Sep 17 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 Bruno Medeiros wrote:

 Regan Heath wrote:

 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



 Ok, I know you were talking first about current D behavior, but I 
 was talking about your suggested solution. You do understand why 
 that solution wouldn't work as you expected?



 Nope.

 Are you referring to your comment:
 "Removing the context pointer would imply having different, 
 incompatible versions of the Inner class, and since that alters 
 program semantics the compiler cannot do that"

 ?

 Regan



 No, I mean making the context pointer static.



 Please explain why it wont work (as I expect - assuming you're not 
 confused about what I expect too <g>)?

 Regan



 Damn it, I already did! :P
 You said you wanted to "have only X outer references, instead of X*Y 
 outer references", right? And like I said, if you (or the compiler) 
 made the context pointer static (as in 'static' storage class in a var 
 declaration), you would have only 1 outer reference (not X), since 
 static would make that "variable" unique.



 Doh!  Somehow I totally missed that, you're quite correct. :)
 
 Regan



Finally! :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 18 2007
prev sibling parent coxalan <coxalan web.de> writes:
Hello,

thanks for all the answers on this topic. Now I understand that with the
current implementation of inner member classes, it is _not_ possible to drop
the context pointer for final outer classes.

Regan Heath Wrote:

 Should static outer references be the default behaviour?  It seems to be 
 a neat little optimisation, assuming it doesn't cause destruction 
 problems as described above and maybe even then.
 
 The only case I can imagine wanting a seperate outer reference for each 
 inner class is when I need to move inner classes from one outer to 
 another, eg
 
 auto o = new Outer;
 auto p = new Outer;
 auto i = new o.Inner;
 i.outer = p;
 
 I'm not sure this is even possible currently and I can't think of a 
 reason why you might want to do this.
 
 Regan



This is quite similar to my feelings about member classes:

Consider again:

class Outer {
    class Inner {
    }
}

main() {
    Outer o = new Outer;
    o.Inner i = o.new Inner;
    

    Outer o2 = new Outer;
    o2.Inner i2 = o2.new Inner;
}

In my dream world the preferable behaviour of inner member classes would be
like this:

Then the type of 'i' should be 'o.Inner'. That would imply that the reference
pointer to 'o' is part of the type, and thus there is no need to store is.
Furthermore, 'o.Inner' and 'o2.Inner' would be different types and thus, they
could have different static class members.

But the real behaviour is this:
Although I write 'o.Inner' above, I could have written 'Outer.Inner' as well,
and really the type of 'i' is 'Outer.Inner' and not 'o.Inner'. That means that
the context pointer cannot be dropped (because for example I could do i2=i),
and that 'o.Inner' and 'o2.Inner' have the same static namespace.

Like Regan i wonder if there are cases where the 2nd behaviour is the better
one, and if yes, what such a case looks like.


I know that the first variant which I would like to see raises some issues:
* 'o' probably should be final.
* The problem addressed by Kirk McDonald: 'o.Inner' objects could have a longer
lifetime than the outer Object 'o'. This could be solved in two ways: Firstly,
the garbage collector does not delete 'o' as long as 'o.Inner' objects exist.
Secondly, allow 'o.Inner' objects only within the scope of 'o'.
* The main problem: The symbol 'o' only exists within its scope. So the type
'o.Inner' only exists within the scope of 'o'.

coxalan
Sep 20 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
coxalan wrote:

 Hello,
 
 Consider this code:
 
 class Outer {
     class Inner {
     }
 }
 
 void main() {
     final Outer o = new Outer;
     o.Inner i1 = o.new Inner;
     o.Inner i2 = o.new Inner;
     o.Inner i3 = o.new Inner;
 }
 
 According to http://www.digitalmars.com/d/class.html, each "o.Inner" instance
contains a "context pointer" to the enclosing outer class.
 
 But in this case the enclosing outer class "o" is final, so in my opinion
there is no need to store the context pointer in i1, i2 and i3 again and again.
Instead, always the address stored in the reference "o" could be used.
 
 Now two questions:
 
 1) Would it be possible to have an optimization in the D compiler which
removes the context pointer in the case of final outer classes? Or will that
result in other problems I currently do not realize?
 



No. Removing the context pointer would imply having different, 
incompatible versions of the Inner class, and since that alters program 
semantics the compiler cannot do that. (unless it was an incredibly 
smart compiler capable of performing whole program optimizations, 
something which at this point is like sci-fi :P). You'd have to 
explicitly state that in the program. (see below)


 2) With the current dmd compiler, is there a way (maybe using template magic)
for a similar object design which circumvents the context pointer?
 
 A suggestion was made here:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58154
 But the problem with that code is that I cannot have more than one outer class
of the same type possessing inner classes.
 
 Thanks,
 
 coxalan



I was thinking the following:

   class Outer {
   }

   class Inner(alias outer) {
     static assert(is(outer : Outer)); // Just a check
   }

   final Outer o1 = new Outer();
   final Outer o2 = new Outer();

   void main() {
       Inner i1 = new Inner!(o1);
       Inner i2 = new Inner!(o1);

       Inner i3 = new Inner!(o2);
       Inner i4 = new Inner!(o2);
   }


Having each Inner class parameterized with an alias, is like having a 
compile-time constant member (the outer variable). This poses some 
restrictions though: the outer classes variables cannot be declared 
inside functions (because variables inside functions cannot be used as 
alias parameters), and the Inner classes are no longer compatible 
(covariant) with each other, although you can create a common Inner 
superclass.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 16 2007