Michael Bruck
2014-10-15 07:14:42 UTC
Hello everyone,
I am looking for feedback on the outline for a proposal below. I would like
to know if there is interest in such a feature and any ideas on
improvements.
Regards,
Michael
Deleting local variables
Summary
This proposal introduces a way to end the scope of a variable before its
enclosing block ends.
{
std::string foo, bar;
...
delete local foo, bar;
...
}
Motivation
The â} operatorâ is powerful but but comes with a pre-defined destruction
order which is not suitable for all applications. In real world programs
the desired scopes of objects are not always cleanly nested but sometimes
overlap in complex ways.
Sometimes objects hold expensive resources and especially with programming
patterns like threading or resumable functions the resources can remain
blocked long after use if other functions in the same block require a long
time to complete.
This leads to programming patterns that try to mitigate this problem in
suboptimal ways. A typical approach looks like:
{
auto file = file_open_rlock("data_snippet");
auto blob = file.fetch_all();
file.close();
auto conn = connect_to_peer("192.128.0.1");
conn.send(blob);
blob.destroy();
auto reply = conn.fetch_reply();
conn.disconnect();
auto file2 = file_create("output");
file2.write(reply);
reply.destroy();
file2.close();
}
There are a number of problems with this solution:
-
The library needs to provide a function that releases expensive
resources in addition to the destructor.
-
The library needs to keep track of the additional state in which
resources are freed but the object not yet destroyed.
-
The user needs to locate such a function and understand its semantics to
see if it really releases enough resources.
-
The neutered object still lingers in some form on the stack until the
end of the scope.
-
The compiler can not diagnose at compile time when such an already
neutered object is used accidentally due to code rewrite etc.
-
Diagnostics and other interactions that are tied to the destruction
occur far removed in time from the time the object actually falls out of
use.
This proposal would allow for the following code:
{
auto file = file_open_rlock("data_snippet");
auto blob = file.fetch_all();
delete local file;
auto conn = connect_to_peer("192.128.0.1");
conn.send(blob);
delete local blob;
auto reply = conn.fetch_reply();
delete local conn;
auto file = file_create("output");
file.write(reply);
delete local file, reply;
}
Details
Unlike the regular delete expression the argument is not a pointer but
rather a list of variable or function parameter names.
Variables in the enclosing scope cannot be deleted from within selection
statements (if, switch), iteration statements (while, do, for), catch
clauses or other conditionally executed code.
When goto crosses delete local in the direction of the program flow then it
deletes the object in the same way as when crossing â}â. When goto passes delete
local it must also pass the point of declaration of the name.
Optional: After delete local the name is free for reuse in a new variable
declaration.
I am looking for feedback on the outline for a proposal below. I would like
to know if there is interest in such a feature and any ideas on
improvements.
Regards,
Michael
Deleting local variables
Summary
This proposal introduces a way to end the scope of a variable before its
enclosing block ends.
{
std::string foo, bar;
...
delete local foo, bar;
...
}
Motivation
The â} operatorâ is powerful but but comes with a pre-defined destruction
order which is not suitable for all applications. In real world programs
the desired scopes of objects are not always cleanly nested but sometimes
overlap in complex ways.
Sometimes objects hold expensive resources and especially with programming
patterns like threading or resumable functions the resources can remain
blocked long after use if other functions in the same block require a long
time to complete.
This leads to programming patterns that try to mitigate this problem in
suboptimal ways. A typical approach looks like:
{
auto file = file_open_rlock("data_snippet");
auto blob = file.fetch_all();
file.close();
auto conn = connect_to_peer("192.128.0.1");
conn.send(blob);
blob.destroy();
auto reply = conn.fetch_reply();
conn.disconnect();
auto file2 = file_create("output");
file2.write(reply);
reply.destroy();
file2.close();
}
There are a number of problems with this solution:
-
The library needs to provide a function that releases expensive
resources in addition to the destructor.
-
The library needs to keep track of the additional state in which
resources are freed but the object not yet destroyed.
-
The user needs to locate such a function and understand its semantics to
see if it really releases enough resources.
-
The neutered object still lingers in some form on the stack until the
end of the scope.
-
The compiler can not diagnose at compile time when such an already
neutered object is used accidentally due to code rewrite etc.
-
Diagnostics and other interactions that are tied to the destruction
occur far removed in time from the time the object actually falls out of
use.
This proposal would allow for the following code:
{
auto file = file_open_rlock("data_snippet");
auto blob = file.fetch_all();
delete local file;
auto conn = connect_to_peer("192.128.0.1");
conn.send(blob);
delete local blob;
auto reply = conn.fetch_reply();
delete local conn;
auto file = file_create("output");
file.write(reply);
delete local file, reply;
}
Details
Unlike the regular delete expression the argument is not a pointer but
rather a list of variable or function parameter names.
Variables in the enclosing scope cannot be deleted from within selection
statements (if, switch), iteration statements (while, do, for), catch
clauses or other conditionally executed code.
When goto crosses delete local in the direction of the program flow then it
deletes the object in the same way as when crossing â}â. When goto passes delete
local it must also pass the point of declaration of the name.
Optional: After delete local the name is free for reuse in a new variable
declaration.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.