[Development] Notes on QtCore session @ QCS2016
thiago.macieira at intel.com
Tue Sep 6 02:02:50 CEST 2016
Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo
> 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
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?
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
PPS: those decisions will be documented as QUIPs.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development