On 9/02/2016 16:14, Phil Bouchard wrote:
Getting back on topic, one of the things that bothers me about block_ptr (from looking at the docs only) is that it appears to be incompatible with async methodologies, where memory is constructed and then pushed into a queue somewhere for later action (and sometimes that queue is in application code, sometimes in Boost.Asio or a similar reactor, and sometimes in the OS itself, and often all three at different times). From what I can tell, these would be treated as orphaned pointers and be subject to destruction mid-operation. Or am I missing something?
I would need some code example to look into this specific use case.
This is probably not the best example of the case, but it's at least one that's convenient to hand. Consider http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/.... While the read/write operations are "in flight", the "self" variable is a shared_ptr that's stored in some arbitrary location (most likely heap-based, since the caller stack will be destroyed) that's defined by a combination of the compiler's lambda generation and Asio's callback handler management. Now, this implementation assumes that only one operation (either read or write, but not both) can be in flight at once, and so it also uses member fields for the buffers. Imagine similar code where that doesn't hold, and (ignoring performance considerations for the moment), imagine that the start of the operation allocated the buffer locally and then passed ownership of it to the "operation", to finally be released inside the handler. I don't see how any of these pointers could be block_ptrs without breaking things, unless its definition of "being on the stack" includes being in a deferred lambda. Perhaps this isn't an intended use, but the docs seem a bit light on examples of real-world use and where you should use one of these rather than some other pointer type.