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

André Pönitz apoenitz at t-online.de
Sun Nov 20 12:53:11 CET 2016


On Fri, Nov 18, 2016 at 08:37:26PM +0100, Marc Mutz wrote:
> 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.

If Qt *requires* a dependency that does not care about BC and
leaks it into its interface, this effectively voids the value
of Qt's current BC promise for the user, as, as you correctly
stated, the burden of taking care of dependencies is now shifted
to the sholders of a user caring for BC.

Now we can discuss how much of a total loss of value of Qt that
would be. My personal guess on a first approximation is "zero,
because nobody is really affected". Typical users of Qt are:
- people using Qt in a restricted environment that ship their
  application themselves, bundled with everything they use 
  (read "Windows", or "certified environment", or "devices") 
  They are not affected by BC breakages. If they need to update
  stuff they go from one blob to another blob, the only 
  difference Qt BC in that scenario might be is the size of
  the delta blob.
- people using Qt in applications distributed by packaging
  systems (read "Linux distributions"). They are not affected
  by BC breakages.
- people providing packaging systems. They *are* affected. But
  since they already take care of a lot of other dependencies
  not caring for BC, Qt being on one side of the fence or the
  other does not make a fundamental difference.

So: If you want to argue that using GSL, and std::exception
would be beneficial for Qt, you might want to start with 
making a point about the value of the current BC promise.

Andre'



More information about the Development mailing list