Overview
Features
Download
Documentation
Community
Add-Ons & Services

Breaking Changes for 2.0 - shared pointers? threading?

A general discussion forum.

Breaking Changes for 2.0 - shared pointers? threading?

Postby jmansion » 18 Aug 2009, 17:21

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
jmansion
 
Posts: 15
Joined: 01 Aug 2006, 14:42

Re: Breaking Changes for 2.0 - shared pointers? threading?

Postby guenter » 22 Aug 2009, 10:01

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).
guenter
 
Posts: 1107
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Breaking Changes for 2.0 - shared pointers? threading?

Postby jmansion » 26 Aug 2009, 14:34

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.

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?
jmansion
 
Posts: 15
Joined: 01 Aug 2006, 14:42

Re: Breaking Changes for 2.0 - shared pointers? threading?

Postby guenter » 31 Aug 2009, 20:39

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.
guenter
 
Posts: 1107
Joined: 11 Jul 2006, 16:27
Location: Austria


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron