digitalmars.D - scope(exit): exception safety article example incorrect?
- Tim Keating (15/15) Apr 03 2007 The article on exception safety
- BCS (3/21) Apr 03 2007 Good point, and I think you are correct, but I think the intent is still...
- Lionello Lunesu (3/23) Apr 04 2007 On win32, it could be a named mutex, with the name hardcoded :P
The article on exception safety (http://www.digitalmars.com/d/exception-safe.html) uses this example: void abc() { Mutex m = new Mutex; lock(m); // lock the mutex scope(exit) unlock(m); // unlock on leaving the scope foo(); // do processing } However, it seems to me this won't actually work as written. Doesn't any variable used for scoping need to be declared either static or outside the scope it's protecting? As written, it looks to me as though a new local m will be created on the stack each time a thread enters this func, which won't protect anything! TimK
Apr 03 2007
Reply to Tim,The article on exception safety (http://www.digitalmars.com/d/exception-safe.html) uses this example: void abc() { Mutex m = new Mutex; lock(m); // lock the mutex scope(exit) unlock(m); // unlock on leaving the scope foo(); // do processing } However, it seems to me this won't actually work as written. Doesn't any variable used for scoping need to be declared either static or outside the scope it's protecting? As written, it looks to me as though a new local m will be created on the stack each time a thread enters this func, which won't protect anything! TimKGood point, and I think you are correct, but I think the intent is still clear.
Apr 03 2007
Tim Keating wrote:The article on exception safety (http://www.digitalmars.com/d/exception-safe.html) uses this example: void abc() { Mutex m = new Mutex; lock(m); // lock the mutex scope(exit) unlock(m); // unlock on leaving the scope foo(); // do processing } However, it seems to me this won't actually work as written. Doesn't any variable used for scoping need to be declared either static or outside the scope it's protecting? As written, it looks to me as though a new local m will be created on the stack each time a thread enters this func, which won't protect anything! TimKOn win32, it could be a named mutex, with the name hardcoded :P L.
Apr 04 2007