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
