[Interest] Advice on QSharedPointer versus QExplicitlySharedDataPointer
Constantin Makshin
cmakshin at gmail.com
Fri Jul 19 21:31:48 CEST 2013
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130719/7a7a6ed9/attachment.html>
More information about the Interest
mailing list