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

Lars Knoll lars.knoll at qt.io
Fri Nov 18 09:30:03 CET 2016


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.

Cheers,
Lars




More information about the Development mailing list