Bill Baxter wrote:
On Fri, Oct 2, 2009 at 8:33 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
I think this has been discussed in this group already.
An object storing another object needs two allocations:
class A { ... }
class B {
A a;
this() {
a = new A;
}
}
auto b = new B; // two allocations
I'm thinking of using "scope" in this situation to imply in-situ storage:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That means
the constructor needs special scrutiny, in particular a cannot be null
because that wouldn't make much sense.
What do you think?
I think it would be nice, but there are enough issues that I'm not
convinced that saving a few allocations is worth it.
Mainly what happens if you do someB.a = someOtherA later on?
The answer to that might be different than how you treat someB.a = new A().
The latter could be converted into a placement new. But the former
has to still point to the original someOtherA to maintain proper
reference semantics.
You can sidestep these issues by saying that a scope A in a class is
not rebindable. But that no doubt cuts out some useful cases.
Yah, the idea was to make it not rebindable. Initially I even thought of
using "final" instead of "scope".
Another option would be to make "scope A" reserve space for both a
pointer to an A and the memory for it. Then the someB.a is just a
regular A reference that can be rebound like any other, or made null
if desired. It would just leave orphaned memory sitting there if
rebound to point to some other A. Or it could use placement
construction if you assign a new A to it. (but not if you say
someB.a = new DerivedFromA()).
Having a reference plus in-situ storage also crossed my mind, but I
think it would serve corner cases that could best be served by either
using two allocations, or having the user herself define one reference +
one scope object.
Andrei
