[Development] Notes on QtCore session @ QCS2016

[Thiago Macieira]

Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo 
escreveu:
> Random comments:
> 
> Il 02/09/2016 17:01, Thiago Macieira ha scritto:
> > https://wiki.qt.io/QtCS2016_QtCore
> > 
> > * Deprecation of APIs
> > 
> >     * qrand/qsrand -> replacement is Standard Library or your own
> 
> Unfortunately there's no replacement for a thread safe, easy to use,
> deterministic, low quality random number generator. std::rand is not
> thread safe and the whole random API is not exactly user friendly...

I don't think we care enough about providing a low-quality generator. The 
discussion we had was about high-quality ones, possibly FIPS certified.

You're right the std:: API is not user-friendly. In fact, it's plainly user-
hostile, requiring multiple template arguments, creating objects that should 
only be used with auto, and has a major problem with properly seeding the 
entropy in certain scenarios. Still, the conclusion of the discussion is that 
we don't to write a wrapper API. We should get the high-quality generator and 
that should suffice for everyone.

> > * QStringView & QByteArrayView
> > 
> >     * Deprecate QStringRef
> >     * Not QArrayView: discuss later
> 
> IOW: the views will have the full blown QByteArray/QString API on them?

Like Marc said.

> > * allocator for QObject
> > 
> >     * custom operator new()
> >     * might conflict with combined moc space savings
> >     
> >         * which conflicts with includemoc for Clang warnings
> 
> It would be interesting to know how all the problems with custom
> operator new()s have been solved by this approach (for instance, how
> does this handle objects created in one shared object and destroyed in
> another?)

No such problem exists in the first place.

It can only happen if you're mixing MSVC runtimes, which is not supported.

> > * C++11 Standard Library compatibility list
> > 
> >     * no volunteers yet
> 
> Is this a matter of converting this documented into qdoc?
> 
> https://codereview.qt-project.org/#/c/142782/

We decided to make a QUIP out of this, in a later session. Stay tuned.

> > * C++ ABI
> > 
> >     * libstdc++ still breaking compatibility in std::function
> >     * not now, revisit in a year or two
> 
> There hasn't been time to discuss this at QtCon, but I'd say we should
> not spend another year before revisiting this at the next QtCS: do we
> really care about C++ ABI compatibility? What other C++ libraries are
> doing this? Do users really expect to swap out standard library
> implementations without the need of recompiling libraries and
> applications that use them? Or is it an artificial problem we're
> imposing on ourselves?

I think there was enough time to discuss it, we did discuss it, and we 
concluded that it's still important enough that we don't want to depend on the 
ABI right now. In fact, given that libstdc++ is breaking ABI across its own 
versions, it's not even a problem of libstdc++ vc libc++ compatibility (which 
is also still broken in all Linux distros I've seen)..

The "a year or two" revisit is to check how relevant the breakages that we are 
currently aware of are, at that time. If they are safely in the past and don't 
affect much, and if GCC folks have stopped playing with the voltage in the 
power switches, we can reconsider.

PS: QCS discussions are proposals. They become decisions once the ML agrees on 
it.

PPS: those decisions will be documented as QUIPs.

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