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

Poenitz Andre Andre.Poenitz at theqtcompany.com
Mon Mar 21 14:35:49 CET 2016


Sean Harmer <sean.harmer at kdab.com> wrote:
> On Monday 21 March 2016 12:23:44 Poenitz Andre wrote:
> > 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. 

Is a receiver of this "event-like object" meant to be able modify the shared
data while the other receiver keep hold of their "copy", i.e. is this effectively
as shared_thing<const Foo> or is it a conscious decision to let receivers
modify object state behind other receivers' back?

In the first case, the shared ptr should be an implementation detail of
the class and the class itself made appear to have value semantics.
No need for the user to worry about ownership at all.

The second case should be banned to start with. Making something
modifiable, creating multiple ways to access it, and relying on distant
parts of an application to cooperate when modifying that state is 
calling for trouble. 

> > 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.

Just replacing a naked pointer by a shared pointer does not solve the 
ownership problem. At best, it addresses part of the lifetime aspect.

"Being modern for the sake of being modern" is also no a good enough 
reason here. The trend seems to go towards value semantics lately.

Andre'


More information about the Development mailing list