From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-07-03 16:52:17
On Tue, Jul 1, 2008 at 10:40, David Abrahams <dave_at_[hidden]> wrote:
> Beman Dawes wrote:
>> The remove(p) function is currently specified to return a bool with a
>> value of exist(p) before the post-condition is established. The
>> post-condition is !exists(p).
> You can't really guarantee that, can you? Can't some other process
> sneak in and re-create p before remove returns?
There's a blanket "Effects and Postconditions not guaranteed in the
presence of race-conditions" in effect for the whole library:
>> Thus I'd like to change the return to void. Although that will break
>> some code, the breakage will result in a noisy compile-time error that
>> is easy to fix by inserting a call to exits() before the call to remove().
> Sounds like you're making the right choice here.
Sounds good to me too. If there's a potential race there anyways,
might as well let the user write it explicitly.