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

[Marc Mutz]

On Monday 21 March 2016 13:38:43 Sean Harmer wrote:
> On Monday 21 March 2016 12:23:44 Poenitz Andre wrote:
> > 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?
> 
> 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 <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts