On Monday 21 March 2016 13:38:43 Sean Harmer wrote: > On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > > Marc Mutz <[email protected]> wrote: > > > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > > > Marc Mutz <[email protected]> wrote: > > > > > I said then and I repeat it now that imho template aliases are not > > > > > interesting for library development. In particular, I don't think > > > > > something like > > > > > > > > > > > > > template<typename T> > > > > > > > > using QNodeCreatedChangePtr = > > > > > > > > QSharedPointer<QNodeCreatedChange<T>>; > > > > > > > > > > should be part of an API of a library. We have auto to avoid having > > > > > to type this type. The typedefs just hide the (essential) fact > > > > > that this is > > > > > a shared pointer type. > > > > > > > > Do I understand correctly that you argue that the fact that the > > > > actual type is a shared pointer is so important that it shall not be > > > > hidden by a template alias whereas it would be completely fine to > > > > hide everything related to type by using auto? > > > > > > Yes, you understood me correctly. > > > > > > And to answer your implied objection, too: > > > > > > No, there's no contradiction, because auto is for use in > > > implementations and I was talking explicitly about APIs (which implies > > > API documentation, too). It's one thing to write > > > > > > auto o = factory->create(); > > > > > > and quite another to have > > > > > > QNodeCreatedChangePtr<Foo> create() [virtual] > > > > > > (to make up a plausible, but nonsensical example) in the docs. > > > > > > Thanks, > > > Marc > > > > I will argue that if user code looks ugly by default, or needs one > > specific, controversial coding style when using an API, the API is bad. > > > > A possible question here is why there's a need to have the QSharedPointer > > show up in the API at all. > > > > Is it meant to be a vehicle to provide value semantics? If so, why isn't > > the sharing hidden in the implementation of the object? > > > > Is it meant to hide unclear ownership and object lifetime? If so, > > shouldn't ownership and lifetime better be clear? > > It's to support one-to-many delivery of an event-like object to backends > potentially running on multiple threads concurrently. The type is not a > QObject so can't be managed by the QObject parent-child relationship. Using > a naked pointer
But QSharedPointer *is* a naked pointer. That is, if you're referring to Sean Parent's definition in his goal of "No raw pointers". > goes against modern C++ recommendations and would mean > having to put in place code to delete the objects after all consumers are > done with it. If you follow Sean Parent, then you should hide the naked shared pointer in an object with value semantics. In Qt we'd say a CoW type, but the type may not need to allow writing. > A QSharedPointer to a QNodeCreatedChange which is a templated type works > well here and I'm using the create() static to avoid having two > allocations instead of one per event. -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
