scope(~this)

[Inquie via Digitalmars-d-learn]

On Tuesday, 14 March 2017 at 05:33:28 UTC, thedeemon wrote:
> On Monday, 13 March 2017 at 14:28:01 UTC, Inquie wrote:
>> On Monday, 13 March 2017 at 05:18:18 UTC, Nicholas Wilson 
>> wrote:
>>> On Sunday, 12 March 2017 at 21:38:44 UTC, Inquie wrote:
>>>> Is there any easy way to create a scope for termination of 
>>>> the object?
>>>>
>>>> I have a template method that takes a type and allocates and 
>>>> deallocates based on that type.
>>>>
>>>> class bar
>>>> {
>>>>    void foo(T)()
>>>>    {
>>>>       T x;
>>>>       alloc(x);
>>>>       scope(~this) dealloc(x); // hypothetical that wraps 
>>>> the statement in a lambda and deallocates in the destructor
>>>>
>>>>       ... x must stay allocated until class instance 
>>>> termination(has to do with COM, can't release it in foo)
>>>>    }
>>>>
>>>> }
>>>>
>
> I think the feature you're asking for is too 
> complicated/involved for a language feature. Because it means 
> there must be some implicit array in each object of your 'bar' 
> class that holds some number of closures that will be executed 
> in destructor. This affects object's memory layout and raises 
> questions of allocating memory for those closures and since 
> those closures will have pointers to some data (like 'x' here) 
> it affects garbage collection. So there are a lot of things to 
> be careful about and things that might affect other language 
> features we haven't thought about yet. This is something quite 
> big and something that affects a lot of code, not just a couple 
> of classes you'll write in your one app. Probably it would be 
> better to implement it as a library feature. Just make a base 
> class having a method for registering such closures and calling 
> them in destructor, and inherit from it or just embed it in 
> your 'bar'.

Complexity is in the eye of the beholder. Children think many 
things are complex when they are not.

If a library solution could be created that is as seamless as a 
language solution, then I guess it would work.  The downside of a 
library solution is uniformity of syntax and added verbosity.

There is really no any arrays to keep track of or anything like 
that matter you stated. It requires creating a delegate to wrap 
the scope block and a copy of the variable to one on the heap. 
The GC uses arrays and that happens regardless. No reason for the 
compiler to create a new array.

3 steps:

1. Compiler copies local variables to heap(the "closure" part, 
which actually means it is not closing anything as a normal 
delegate would require).

2. The compiler creates a delegate. No big deal, does this in 
many places.

3. The compiler calls all the delegates on destruction. The only 
new part. But not difficult.



Create a ScopeThis(...) and adds no extra overhead would be nice 
but I see that as being more complex. How can we determine what 
are variables that need to be copied to the heap? How can we hook 
in to the ~this? (can't have multiple ones, can we?)

If you can come up with a working ScopeThis that doesn't have any 
more overhead than a language version, I'd be all for it, I don't 
know or see how it could be done.

>>>>       ScopeThis!("dealloc(x);")

Must determine that x is a variable(hard?) and copy it to the 
heap(easy). Must create access to any local functions used(e.g., 
if dealloc is local). Then must hook in to ~this to execute the 
code.

It would be nicer to not have to use a string but it would work 
easy since we could use a mixin and modify the string easily once 
we could parse it.