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.
