Yes it was, you wrote that smart_ptr asserted because that was better than dereferencing a null ptr so my question/point is why throw rather than assert because locking an already locked mutex (as Peter pointed out) is undefined behaviour. Similar results in the end so why assert in one and throw in the other? Why not throw in shared_ptr then?Ok, but what happens if locking an already locked mutex where undefined behaviour? This isn't this the same as the smart_ptr case? Who knows how the actual implementation is on all the platforms, or future platforms?
Um, wasn't the question throw vs assert? In either case we would detect the attempt to relock the lock and not do that.
Because there's a difference you don't see. The assert in smart_ptr is merely replacing one crash (or memory corruption) with an immediate crash that is easier to debug. In neither case would the program get a chance to recover or clean up.
In the thread lock case, the throw avoids the undefined behavior entirely, since it doesn't ever do the underlying OS lock action that causes the undefined behavior.
-- Jon Biggar Floorboard Software [EMAIL PROTECTED] [EMAIL PROTECTED]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
