"Peter Dimov" <[EMAIL PROTECTED]> writes: > Unspecified, but I don't think we can avoid that with the low-level > interface. High level wrappers that package creation and execution would be > immune to this problem.
Is there really a need for a low-level async_call interface? After all, the existing threads interface provides all the low-levelness you can handle. >>>> Actually, there's another minor issue as well. The user can call >>>> operator() and then let the async_call go out of scope with out ever >>>> calling result(). Mayhem would ensue. The two options for dealing >>>> with this are to either block in the destructor until the call has >>>> completed or to simply document this as undefined behavior. >>> >>> Yes, good point, I missed that. >> >> I lean towards simple undefined behavior. How do you feel about it? > > Seems entirely reasonable. I don't think that we can "fix" this. Accessing > an object after it has been destroyed is simply an error; although this is > probably a good argument for making async_call copyable/counted so that the > copy being executed can keep the representation alive. Seems like this is also pointing at a high-level interface... -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
