[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marc Mutz]

On Friday 18 November 2016 09:30:03 Lars Knoll wrote:
> On 17/11/16 23:03, "Development on behalf of Thiago Macieira" <development-
bounces+lars.knoll=qt.io at qt-project.org on behalf of 
thiago.macieira at intel.com> wrote:
> >    On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote:
> >   > The bigger problem is that while owner<T> does not affect the ABI,
> >   > all other
> >   > 
> >    > GSL types do, and we're back to our §$%&!§ rule that we can't accept
> >    > other libs' types in our ABI, preventing anything other than
> >    > owner<T> from being added to Qt.
> >    
> >    We can't accept the Standard Library ABI in our ABI as per previous
> >    decisions (that I guess will be revisited once we get the QUIP on it
> >    up).
> 
> Yes, once we have the QUIP process up and running (very soon now), I am
> open to revisiting this and start creating QUIP containing a whitelist of
> stuff from the STL that we want to allow in our APIs.
> 
> >    But GSL is another story. If it is sensibly developed, with a promise
> >    to binary compatibility for extended periods of time and no nonsense
> >    stuff like inline namespaces, we could accept it. Especially the
> >    header-only parts of it.
> >    
> >    As for whether we can accept in our *API*, that depends on whether we
> >    would force our users to learn something alien to Qt or it, and what
> >    the benefits would be. Similar to the "empty()" function case.
> >    
> >    PS: IMO, the name of the library is inconvenient. It's too close to
> >    GLSL and GST (GStreamer). Of course, not a reason not to use it.
> 
> Let's wait a bit how this develops, and whether they are even interested in
> keeping compatibility between versions. But it would be another
> dependency, something I don't want to introduce without getting enough
> benefit out of it.

The GSL is header-only. There are no BC guarantees, and, "worse", there are 
different implementations. All the compiler, or a static checker, cares about 
is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span. It 
does not care about the implementation.

There's no reason for Qt to extend its BC guarantees to other libraries. STL, 
GSL, Boost, std::exception, you name it. They are outside of Qt's realm and 
therefore do not fall under the Qt BC rules. As with every other C++ library: 
if a user wants BC, it's his job to pin libs without BC guarantees to a fixed 
version. Not Qts.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts