[Interest] Advice on QSharedPointer versus QExplicitlySharedDataPointer

[Michael Jackson]

Thanks for the thoughts. As much as I _think_ I want to use the "Copy on Write" semantics and design pattern I think a straight substitution of QSharedPointer for the Boost SharedPointer will get us to where we want to be. It just seems like a lot of work to reimplement all the classes with a QExplicitlySharedDataPointer code when we will end up using the class in the same way as usual. I am sure I am missing some side effect but the 2 designs seem, at a higher level, almost the same. Currently we have a Macro that each case uses that declares all the typedefs and static functions to create an instance of the class. An update to the macro is pretty much all I am going to need to do to update the bulk of the code.
  Unless I am really missing something.

Thanks
Mike Jackson

On Jul 19, 2013, at 3:31 PM, Constantin Makshin <cmakshin at gmail.com> wrote:

> My 2 cents:
> 
> QSharedPointer is good when you want to use the same object in several places without the need to worry about that object's lifetime because the [automatic] reference counting takes care of that. Another advantage is that it can hold an object of any type, not just ones derived from QSharedData. But if C++11 is acceptable for the project, I'd prefer std::shared_ptr because of std::make_shared which provides more efficient and exception-friendly allocation method.
> 
> Q[Explicitly]SharedDataPointer is used for copy-on-write semantics, i.e. when you want to use one object in several places until something wants to modify it -- in that case the container [semi-]automatically creates a copy of your object and any changes applied to it don't affect other instances. Of course, you can get the same result with QSharedPointer by copying the object when necessary, but Q[Explicitly]SharedDataPointer make things much easier and less error-prone. But their disadvantage is that they require the object's type to be derived from QSharedData (not very nice when the type comes from a third-party library).
> 
>> On Jul 19, 2013 11:01 PM, "Michael Jackson" <imikejackson at gmail.com> wrote:
>> Hello List.
>>    We have a code based that I would like to rewrite parts of in order to get rid of some historical code that does not really help much any more but which may be holding us back in development. The basics of our code base is that we create "Filters", put the into a "Pipeline" container then execute the pipeline. Currently each Filter subclasses from one of our base classes and we implement some typedefs and static functions so that we are always working with a boost/shared_ptr<Filter>. That way we always know that we are dealing with the same instance of the object since we are passing the pointer around all the time. And those pointers are reference counted so they automatically clean themselves up during execution. This all works really well but during our latest design meetings we would like to get rid of some home built base libraries and replace them with QtCore instead. We only use Qt for the GUI side of the program and I think we are really losing out not using Qt for
>>   everything from bottom to top.
>> 
>>   In the design meetings we also started exploring the idea of whether we should just replace the Boost/SharedPointer with QSharedPointer or possibly move to the design pattern that Qt uses with its implicitly and explicitly shared data pointers for each class. I like the idea that the private implementation could be changed out if needed for different circumstances. I have been reading up on the PIMPL design pattern to get a better idea of the pros and cons of both of the approaches we are considering.
>> 
>> I would be interested in the "Qt Pros" thoughts on either pattern, both good and bad.
>> 
>> Thanks
>> --
>> Mike Jackson
>> imikejackson & gmail * com
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest