Visibility of variables in struct nested within a class

[Charles Hixson]

On 07/05/2013 02:52 PM, H. S. Teoh wrote:
> On Fri, Jul 05, 2013 at 01:43:27PM -0700, Charles Hixson wrote:
>> On 07/05/2013 11:25 AM, H. S. Teoh wrote:
>>> On Fri, Jul 05, 2013 at 11:19:53AM -0700, Charles Hixson wrote:
>>>> I have a class that defines a variable (root).  Within it I have
>>>> nested a struct.  If I refer to that variable within the struct I
>>>> get the message:
>>>> cbt2.d(760): Error: this for root needs to be type BTree not type Path
>>>>
>>>> If I change the struct to a class, the error goes away, but I'd
>>>> prefer to use a struct.
> [...]
>> class    Outer
>> {    int    inn;
>>
>>      struct    InnerS
>>      {    int    able;
>>
>>          void    setable()
>>          {    able    =    inn;    }
>>      }    //    InnerS
>> }    //    Outer
> [...]
>
> The problem is that embedded structs don't have an implicit context
> pointer to the containing class, but an embedded class does. See:
>
> 	http://dlang.org/class.html
>
> under "Nested Classes", toward the end.
>
> When using a nested class, writing "able = inn" is actually shorthand
> for "this.able = this.outer.inn": this.outer is the implicit pointer
> that points to the outer class.
>
> There may be a ticket in the bugtracker for supporting nested structs
> with .outer pointers, but AFAIK this currently isn't supported by the
> language.
>
> One solution, if you prefer to use structs, is to implement the context
> pointer yourself:
>
> 	class Outer
> 	{
> 		int inn;
> 		struct InnerS
> 		{
> 			Outer* outer;
> 			int able;
>
> 			this(ref Outer _outer)
> 			{
> 				outer =&_outer;
> 			}
> 			void setable()
> 			{
> 				able = outer.inn;
> 			}
> 		}
> 	}
>
> If you're 100% certain InnerS will never be used outside of class Outer,
> and it is only ever instantiated once inside the class, then you may be
> able to get away with using pointer arithmetic from the this pointer of
> InnerS to compute the reference to class Outer, but you'd be treading on
> tricky ground. Here's an example:
>
> 	class Outer
> 	{
> 		int inn;
>
> 		struct InnerS
> 		{
> 			int able;
>
> 			void setable()
> 			{
> 				// Buahaha
> 				int* innp = cast(int*)(cast(ubyte*)&this - Outer.inner.offsetof + Outer.inn.offsetof);
>
> 				// Behold! No need for context pointer!
> 				able = *innp;
> 			}
> 		}
>
> 		// Don't ever instantiate InnerS except here, otherwise
> 		// things will fail in ugly ways!
> 		InnerS inner;
> 	}
>
> You could, of course, wrap up the ugly pointer arithmetic in a nice
> mixin, and pretty it up with parameters that allows you to use it
> generically for any struct nested in any class. But the above gives the
> basic idea behind it.
>
> Note that pointer arithmetic is *not* recommended in general, as you
> will get memory corruption if you ever instantiate InnerS outside of
> Outer, or more than once in Outer, and then call setable(). But if
> you're desperate to avoid the overhead of an extra context pointer, the
> above may help you. :-P
>
>
> T
>
Well, InnerS should *NEVER* be instantiated outside of Outer.  To ensure 
that every method and variable is private.  OTOH, if I should ever 
decide to implement ranges, I'll need more than one copy.  The "this" 
constructor with a parameter is a bit better, or I may just decide that 
simplicity is worth adding a huge lot of extra indirections, and leave 
it as a class.

This is the kind of thing where any manually maintained change is likely 
to be brittle, so I don't think that pointer arithmetic is at all 
reasonable.

So only the two choices of passing the containing class in the 
constructor and converting it into a class seem reasonable.

Actually, there's a third choice that is probably the one I'll use.  I 
didn't need the struct until I decided to refactor the code to make it 
simpler.  I can just undo the refactoring.  That's an ugly answer, but 
it doesn't sacrifice efficiency.  But first I'll read up on initializing 
struct.s with parameters.  I should understand that more anyway.

Looking over the original code a bit more, I don't think the constructor 
would work, as the tests for error happen during the calls on Inner 
methods.  So it's either class, or undo the refactoring.  And for this 
reason and that, probably that means undo the refactoring.  (It's not 
entirely for reasons of speed.  I'm also considering maintainability.)  
Making it into a class rather than a struct *would* work, but I chose a 
struct because I wanted isolation (for simplicity) without a run-time 
penalty.  But it appears as if it wouldn't work, barring fragile tricks.

-- 
Charles Hixson