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 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. 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. If I can't use the template alias syntax, so be it, I can use the more verbose alternative. Cheers, Sean -- Dr Sean Harmer | [email protected] | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
