On Monday 21 March 2016 12:44:34 Marc Mutz 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.
I'm actually after the implementation case here so I can write: auto creationChange = QNodeCreatedChangePtr<QEntityData>::create(this); rather than: auto creationChange = QSharedPointer<QNodeCreatedChange<QEntityData> >::create(this); Of course it would also be a convenience to the user when they need to do similar. I guess I'll redo my changes if I can't use template aliases like this unconditionally. Cheers, Sean _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
