Breaking Changes for 2.0 - shared pointers? threading?

[jmansion]

Much as I like them (with caveats) - can I propose retiring POCO's smart pointers in favour of the TR1/C++0x versions and deferring to a built-in Boost subset snapshot if the compiler doesn't have support and the system doesn't have Boost?

As far as I can tell this is actually a subtle breaking change for the way that you indicate whether a passed pointer is being gifted for ownership or must be wrapped as shared with other smart pointers. Its a big change, but I can't see how POCO can retain relevance post C++0x if it uses a different style for this sort of thing.

Probably best to line up with the thread and mutex/condvar stuff too, and extend from that.

I'm no fan of Boost but it may be appropriate to import a snapshot of (some of) Boost to provide some low-level componentry and then concentrate on providing value add on top and/or value by supporting stabilised Boost-like APIs where Boost breaks things from version to version.

James

[guenter]

I agree that at some point during the transition to 2.0 we'll have to look at the new C++ features and how to integrate them. While some transitions are relatively straightforward - moving from Poco::SharedPtr to std::shared_ptr should not be too much effort - the threading changes are more of an issue. The best thing to do for now would probably be to keep Poco::Thread and friends, but change its underlying implementation to be based on std::thread (and provide some functions to obtain the underlying std::thread from a Poco::Thread, or construct a Poco::Thread from a std::thread).

[jmansion]

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.

So:

Code: Select all

  AutoPtr<T> foo(new T) ;

and

Code: Select all

intrusive_ptr<T> foo(new T);

have different expectations, beyond addref <-> duplicate.

And while:

Code: Select all

intrusive_ptr<T> bar(foo.get());

works fine,

Code: Select all

AutoPtr<T> bar(foo.get());

will fail.

It will be very tempting for users to attempt a port but pain will ensue. Personally I have tended to favour

Code: Select all

AutoPtr<T>

because, given a raw pointer that I know is owned by an

Code: Select all

AutoPtr<T>

elsewhere, I can do the right thing with the optional parameter - and there is no way to do this with

Code: Select all

SharedPtr<T>

. By implication, nor can you pass an instance of

Code: Select all

T

to a

Code: Select all

SharedPtr<T>

without giving up ownership - so a

Code: Select all

T

that is embedded in something else or on the stack can't be passed to a function parameter defined in terms of

Code: Select all

SharedPtr<T>

or

Code: Select all

const SharedPtr<T>&

, 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

Code: Select all

std::

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?

[guenter]

The plan is just to replace Poco::SharedPtr with std::shared_ptr. Poco::AutoPtr will stay (but possible be renamed to RefPtr, or something like that, with a typedef to AutoPtr), everything else would just be too much pain. Especially since intrusive_ptr will not be part of the next C++ standard anyway AFAIK.

I had a meeting last week with Alex, and one of the things we discussed was the future of POCO. One of the things we consider is dropping the 1.4 release and instead immediately going for 2.0. However, the main problem so far is a lack of resources. We would definitely need someone working full time on POCO to really drive things forward, but currently this can't be done. We have some ideas to improve the situation, but more about this later. As for the repository, for everything past 1.3.x, the trunk in subversion is the master repository.