[Development] INTEGRITY

Thiago Macieira thiago.macieira at intel.com
Fri Sep 20 00:07:38 CEST 2019

On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via Development 
> On 18/09/2019 17:33, Thiago Macieira 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.
> <devil's advocate> it still means that we can't require core language
> conformity from our compilers. And we're talking about C++11's
> constexpr, not C++14's.

I've just checked our changelogs and we've never raised the minimum version of 
GCC from 4.7. That means we can't officially depend on anything that GCC 4.8 
added to the Core Language. They are:

- attributes
- alignas & alignof
- inheriting constructors
- thread_local
- ref qualifiers (4.8.1)

Attributes is a non-issue because we have __has_cpp_attribute / 
QT_HAS_ATTRIBUTE so we end up with macros for most attributes anyway. Alignas 
and alignof are also non-issues because they're rare enough.

Inheriting constructors I'm not sure. It might be getting used without anyone 

Ref qualifiers I know the few places that have them are still under #ifdef and 
thus compat builds.

And thread_local cannot be used because of MinGW (GCC and Clang). See the 
thread on this subject.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

More information about the Development mailing list