guenter wrote:moving from Poco::SharedPtr to std::shared_ptr should not be too much effort
i hope you're right - I think this will cause big trouble for users! Or at least - while this is straightforward, the case of Poco::AutoPtr and boost::intrusive_ptr there looks like a world of pain.
For AutoPtr the object must be created with use-count 1 and the boost pointer assumes 0.
have different expectations, beyond addref <-> duplicate.
It will be very tempting for users to attempt a port but pain will ensue. Personally I have tended to favour
because, given a raw pointer that I know is owned by an
elsewhere, I can do the right thing with the optional parameter - and there is no way to do this with
. By implication, nor can you pass an instance of
without giving up ownership - so a
that is embedded in something else or on the stack can't be passed to a function parameter defined in terms of
, which I find limiting.
I suppose I should also state that I'm looking to use boost and poco - not just poco and C++0x. Not least, it emulates some of the new C++ features already, so my desire would be to implement in terms of boost and let boost delegate to
when that is available.
Anyway - can we start on this sooner rather than later in a public repository?
Is there any expectation that the relationship between the public repo and the AppInf repo will change, in terms of which is used as the master for making releases of the public poco?