February 26, 2014
Am Wed, 24 Apr 2013 13:41:05 +1000
schrieb Manu <turkeyman@gmail.com>:

> >
> >
> > On 24 April 2013 11:02, Diggory <diggsey@googlemail.com> wrote:
> >
> >> On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote:
> >>
> >>> 2013/4/24 Manu <turkeyman@gmail.com>
> >>>
> >>>  "The r-value being passed is assigned to a stack allocated temporary,
> >>>> which has a lifetime that is identical to any other local variable, ie,
> >>>> the
> >>>> lifetime of the function in which it appears."
> >>>> There, I defined it.
> >>>>
> >>>>
> >>> Good definition. If add more,
> >>> "getting address of "scope" parameter would be disallowed, at least in
> >>> @safe code, because it would be regarded as the escape of stack allocated
> >>> temporary."
> >>>
> >>> Kenji Hara
> >>>
> >>
> >> Why does the temporary need to exist any longer than the current statement? (the current lifetime of temporaries are the statement or expression). Surely any longer is just wasting stack space.
> >
> >
> scope ref a(scope ref int x) { return x; }
> void b(scope ref int x);
> 
> b(a(10));
> 
> The temp produced from '10' needs to last longer than a(), because it can
> be returned to b(). Ie, the temp needs the life of any normal local
> declared within that scope.
> 
> Does D attempt to recycle stack
> space from previous short-lived locals within a single function?

That's a backend optimization, not something the
language needs to be built for specifically.

-- 
Marco

February 26, 2014
I feel I should mention a detail I observed. I am working on a library which generates D code from C++ code with wrappers. I found an interesting situation when I realised that I need to do something like this.

void setPosition(ref const(QPoint) point) {
     ...
     // Static array.
     auto stack = smokeStack(&point);

     cls.classFn(..., stack.ptr);
     ...
}

The above resulting in passing a pointer to a D struct which gets a reinterpret_cast on the C++ end and copied from that after that. Because I wish to also allow temporaries for this for obvious reasons, I must change my function signature to a template.

void setPosition()(auto ref const(QPointF) point);

So whatever happens with rvalue references, I would like to see the ability to take the address of an rvalue reference in a completely unsafe manner. (Or is const& an lvalue? I have forgetten my Scott Meyers knowledge.) I would make this an error in @safe functions, but allowable for @system and @trusted.
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »