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

Poenitz Andre Andre.Poenitz at theqtcompany.com
Mon Mar 21 13:23:44 CET 2016


Marc Mutz <marc.mutz at kdab.com> 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.
> 
> 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?

Andre'



More information about the Development mailing list