I just updated my qpid tree (after a little hiatus working on proton) and I was not pleased to see the way qpid-4440 has turned out:
In my (opinionated) opinion the "simpler" fix is actually much worse. I don't see any good justification for introducing a build conditional - this will just become some piece of build magic that people will blindly copy (or not) and won't understand why. Additionally the name of the conditional "_IN_QPID_BROKER" isn't a name available for our use - all symbols beginning underscore followed by and uppercase letter are reserved for the impleementor. I think the original solution with a new safe API returning a shared pointer and an old backward compatible API returning a raw pointer is the much better way to go. I suspect the driving reason for this hacky change is to avoid having boost types leak into client linked code. If this is the case then I recommend using an intrusive pointer instead of a shared pointer and just use the unsafe API but make sure that all internal use of the pointer is safe. An alternative would be to use an opaque handle type which fronts a shared_ptr but doesn't expose it like we do for the messaging API (in qpid/messaging/Handle.h) Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
