scope class members -> in-situ

[Bill Baxter]

On Fri, Oct 2, 2009 at 8:33 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at 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.

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()).


--bb