Recent changes for QPID-4449

[Andrew Stitcher <as...@redhat.com>]

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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org