[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?
Marc Mutz
marc.mutz at kdab.com
Fri Nov 18 20:37:26 CET 2016
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
More information about the Development
mailing list