[Interest] What don't you like about Qt?

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 09:08:09 PDT André Somers wrote:
> Op 20/09/2016 om 22:09 schreef Alejandro Exojo:
> > On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:
> >> Yes, but for instance you can't move-pass an object between signals and
> >> slots across a queued connection, unless I'm wrong. You have to make your
> >> object implicitely shared. This causes lots of copies when passing a
> >> std::vector, for instance.
> > 
> > The Qt style on designing signals, is to use those for indicating that
> > something happened, but not passing the something in the signal. For
> > example, you get a signal that new data is available (e.g. a datagram),
> > but you don't get the datagram passed as signal argument.
> 
> You don't? Well, you can certainly get a pointer to it (which is cheap,
> of course)...
> See QNetworkAccessManager::finished(QNetworkReply *reply); [signal]

That's to indicate *which* reply finished. That's not passing actual data, 
since you probably already had a pointer to this QNetworkReply anyway.

Similarly to bytesWritten(qint64): it tells you how many bytes were written 
and we found that it's the most common action that happens in the slot. 
Compare to readyRead(): it could have told you how many bytes were read, but 
it would never give you the bytes that were read. That's up to you. And since 
you'd have to read yourself, giving you the count of how many bytes were read 
since the last time wasn't a very useful information.

> I would say that it is quite normal to signal the finishing of some
> operation _and_ directly pass along the results of that operation. If
> that is a std::vector, then indeed it would result in copying (so I'd go
> looking for a different design there, perhaps use a QVector instead).

Signals with non-trivial content are uncommon.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center