digitalmars.D.announce - Lock Options in D article in Dr. Dobb's
- Walter Bright (4/4) Dec 12 2008 Bartosz Milewski has just published "Lock Options" in the January Dr.
- Walter Bright (3/9) Dec 12 2008 Now on reddit:
- Frits van Bommel (28/34) Dec 13 2008 Unfortunately, I'm pretty sure it's buggy :(.
- Nick Sabalausky (12/47) Dec 13 2008 That explains a certain mystery I encountered in a library I wrote.
Bartosz Milewski has just published "Lock Options" in the January Dr. Dobb's. http://www.ddj.com/cpp/212201754 He provides a D implementation of it.
Dec 12 2008
Walter Bright wrote:Bartosz Milewski has just published "Lock Options" in the January Dr. Dobb's. http://www.ddj.com/cpp/212201754 He provides a D implementation of it.Now on reddit: http://www.reddit.com/r/programming/comments/7j7gc/lock_options_a_compiletime_deadlock_prevention/
Dec 12 2008
Walter Bright wrote:Bartosz Milewski has just published "Lock Options" in the January Dr. Dobb's. http://www.ddj.com/cpp/212201754 He provides a D implementation of it.Unfortunately, I'm pretty sure it's buggy :(. In his final implementation he uses a mixin to create a declaration for a scope variable (the lock). That variable will be destroyed before the end of the mixin, not before the end of the containing scope (statement mixins create an implicit scope). See for yourself: ----- module test; import tango.io.Console; class Verbose { this() { Cout("Constructed").newline(); } ~this() { Cout("Destructed").newline(); } } void main() { Cout("Start of main").newline(); mixin("scope lock = new Verbose;"); Cout("End of main").newline(); } ----- Output: ===== Start of main Constructed Destructed End of main ===== It should work without that mixin, but it won't be nearly as nice-looking.
Dec 13 2008
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message news:gi06f7$274a$1 digitalmars.com...Walter Bright wrote:That explains a certain mystery I encountered in a library I wrote. Everything *seemed* like it should have worked with "scope" instead of "auto" but it never did. The variables that were mysteriously unconvertable to "scope" were declared in a mixin. This makes me wonder though: should mixins be implicitly creating a new scope at all? Clearly there are cases where it's desireable to not have that implicit scope, and with the current behavior I don't see a workaround. Are there cases where an implicit new scope would be desired? If so, could those cases be sufficiently worked around by explicitly creating a new scope in the mixin?Bartosz Milewski has just published "Lock Options" in the January Dr. Dobb's. http://www.ddj.com/cpp/212201754 He provides a D implementation of it.Unfortunately, I'm pretty sure it's buggy :(. In his final implementation he uses a mixin to create a declaration for a scope variable (the lock). That variable will be destroyed before the end of the mixin, not before the end of the containing scope (statement mixins create an implicit scope). See for yourself: ----- module test; import tango.io.Console; class Verbose { this() { Cout("Constructed").newline(); } ~this() { Cout("Destructed").newline(); } } void main() { Cout("Start of main").newline(); mixin("scope lock = new Verbose;"); Cout("End of main").newline(); } ----- Output: ===== Start of main Constructed Destructed End of main ===== It should work without that mixin, but it won't be nearly as nice-looking.
Dec 13 2008