[Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]

[Sean Harmer]

On Monday 21 March 2016 12:44:34 Marc Mutz wrote:
> On Monday 21 March 2016 12:07:24 Poenitz Andre wrote:
> > Marc Mutz <marc.mutz at kdab.com> 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