On 2019-09-18 17:33, Thiago Macieira wrote:
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via
Development
wrote:
> We've never required C++11 Standard Library. We've only required the core
> language and the integrity compiler does support it just fine.
Not really, it also fails on constexpr:
https://codereview.qt-project.org/c/qt/qtbase/+/264550
No, it has a bug in its existing constexpr implementation. That's
different.
MSVC 2015 officially supported constexpr, but we turned it off for them
because it was too buggy.
Are we sure to be running the latest version of the GHS compiler?
According to INTEGRITY documentation: "Namespace member
std::condition_variable is not supported, along with any library
functions
related to it (for example, std::notify_all_at_thread_exit)."
So there's no way out of this.
Seems like it. Like I said, we've never required the C++11 standard
library
and we need to be sure the feature we need is supported before we
commit to
it.
https://www.qt.io/blog/2016/06/16/qt-5-7-released
"we require a C++11[-]compliant compiler to build [...] Qt"
The std library is not optional, unless you mean that Qt explicitly
targets free-standing implementations. That, however, is not mentioned.
When we dropped support for pre-C++98-compilers in 5.0, we also removed
-no-stl, because that's natural. There's a technical distinction between
the compiler and the std library, but from the POV of the standard, in
hosted environments, there isn't.
QNX was a case where an older library (by a different vendor) shipped
with a newer GCC, and that limited the use of library features in Qt,
but that particular platform is now gone, and if Integrity has the same
problem as that QNX toolchain had, it should have been removed along
with it. Otherwise, we could've kept QNX along for the ride with no
extra cost to the Qt project.
I think we should be way past caring for non-conforming platforms. We
decided to use SD-6 macros for post-C++14 feature detection, even
thought that meant that none of the features were detected for MSVC, a
much more important platform that Integrity.
The worst thing is that INTEGRITY claims support for C++14 on it's
homepage, even citing the official name of the standard. It *does*
provide std::condition_variable, proven by the fact that the header
exists, can be included and use of std::condition_variable is compiled
without error, so it's clearly positioning itself as a hosted
environment, not a free-standing one. That means that
std::condition_variable needs to be available, or else you're
non-conforming. If you're advertising with conformance, but are in fact
nonconforming, that's misleading advertising, which, at least in EU law,
is punishable.
That, and the fact that the pthreads version we're replacing in
QWaitCondition was working before, makes me think that there can be no
reason not to provide std::condition_variable, because it totally models
pthread's condition variables, so either we're using an old version of
the tool-chain, or the OS, or we're indeed just missing a linker flag.
But no-one seems to know anything (and there's _still_ no maintainer for
the platform listed in the wiki). The best reaction I get is to revert
the patch that introduced use of std::condition_variable. If you would
have a look at how much complexity is taken out of the Qt implementation
of QWaitCondition by simply implementing it on top of the std one, incl.
deleting a rather recent change for just Android, it should be obvious
how this hurts maintainability of Qt. I know Thiago revels in such
details, but there're also those Qt devs who cannot bear the presence of
a find_if. What would the latter half have to say about the four or so
different mutex implementations? While the mutex implementations can be
argued to actually be worth it (though they could be reduced to two:
futex and std::mutex), because futex outperforms std::mutex,
QWaitCondition is _much_ slower (on Windows an order of magnitude) than
std::condition_variable.
Standing in the way of Qt maintainability in this way should disqualify
INTEGRITY as a supported platform until it's resolved.
So, I update my requests:
1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
2. That maintainer should either find the missing linker flag, or file a
bug with Integrity
3. If there's a work-around (providing those missing functions in Qt,
e.g.), apply it, else
4. drop Integrity support (or update to a newer version) ASAP (for Qt
5.15 if not 5.14).
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
