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

[Tobias Hunger]

Hi Marc,

On Fri, Dec 2, 2016 at 8:22 AM, Marc Mutz  wrote:
> As you can see, I was not using it on QObject, as, indeed, the ownership there
> is messed up.

It just does not work with the concepts laid out in the GSL, but that
does not make it messed up.

> But we have tons of take*() and take()-like API, where even in auto-tests,
> which presumably were written by people that know the API well, the return
> value was ignored/leaked, making this kind of API a strong case for use of
> owner<>.

Sprinkling owner<> over our code-base will not magically improve any of this.

> If the Qt low-level smart pointer do not support gsl::owner, then we impair
> users that wish to use the GSL in their own code from using it, because Qt
> code will throw false positives.

Everybody is free to use the STL smart pointers and be done with it.
GSL users will be comfortable with those classes.

Considering that you will get a warning from each and every widget in
a dialog you are probably not going to use enforce GSL owner semantics
in a Qt application anyway.

Best Regards,
Tobias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 02 December 2016 07:45:48 Tobias Hunger wrote:
> Hi Marc,
> 
> Am 28.11.2016 15:33 schrieb "Marc Mutz" :
> > To see how simple gsl::owner markup is to incorporate into Qt, I sat
> 
> down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with
> gsl::owner.
> 
> > https://codereview.qt-project.org/178107
> 
> Owner does not work with Qt's object tree, so this seems like a pointless
> exercise to me. Having some owners but not being able to use them
> consistently is not a big win and already possible with plain C++ smart
> pointers.
> 
> I asked Bjarne Stroustrup at Meeting C++ about Owner and object trees and
> he said that is a memory model that is not supported and that we are on our
> own there.

As you can see, I was not using it on QObject, as, indeed, the ownership there 
is messed up.

But we have tons of take*() and take()-like API, where even in auto-tests, 
which presumably were written by people that know the API well, the return 
value was ignored/leaked, making this kind of API a strong case for use of 
owner<>.

If the Qt low-level smart pointer do not support gsl::owner, then we impair 
users that wish to use the GSL in their own code from using it, because Qt 
code will throw false positives.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Tobias Hunger]

Hi Marc,

Am 28.11.2016 15:33 schrieb "Marc Mutz" :
> To see how simple gsl::owner markup is to incorporate into Qt, I sat
down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with
gsl::owner.
>
> https://codereview.qt-project.org/178107

Owner does not work with Qt's object tree, so this seems like a pointless
exercise to me. Having some owners but not being able to use them
consistently is not a big win and already possible with plain C++ smart
pointers.

I asked Bjarne Stroustrup at Meeting C++ about Owner and object trees and
he said that is a memory model that is not supported and that we are on our
own there.

Best Regards,
Tobias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kevin Kofler]

Marc Mutz wrote:
> To see how simple gsl::owner markup is to incorporate into Qt, I sat
> down, added it to QtGlobal and marked up QScopedPointer (incl. docs)
> with gsl::owner.
> 
> https://codereview.qt-project.org/178107

This is just pointless noise making the code more verbose for no practical 
benefit whatsoever.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On 2016-11-18 20:37, Marc Mutz wrote:

On Friday 18 November 2016 09:30:03 Lars Knoll wrote:

On 17/11/16 23:03, Thiago Macieira wrote:

[...]

>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.

[...]
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.


To see how simple gsl::owner markup is to incorporate into Qt, I sat 
down, added it to QtGlobal and marked up QScopedPointer (incl. docs) 
with gsl::owner.


https://codereview.qt-project.org/178107

Anything other than gsl::owner is hitting the incompatibility wall, but, 
given some form of reliable detection of GSL alternatives, could be used 
with a Qt implementation as a fallback. In that case, Qt would only give 
BC guarantees for the version compiled with its own version of the GSL. 
This is a stop-gap measure to enable the use of more of GSL in Qt while 
still being bound by the current restrictive API rules. Personally, I 
wouldn't bother with anything but gsl::owner until those rules are 
relaxed to allow upstream GSL's types in the ABI.


The use of gsl::owner now also marks places where we might want to use 
unique_ptr in the future, reducing this amount of conceptual work when 
moving to Qt 6.


Thanks,
Marc

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2016-11-22 06:25, Marco Bubke wrote:
> On November 22, 2016 08:17:57 Thiago Macieira wrote:
>> Theming and styling is a complex operation. It's not just "propagating 
>> values". Reading config files will at best get you the right font, correct 
>> icon 
>> set, and somewhat correct colours. But gradients, shapes, complex dialogs 
>> will 
>> not work.
> 
> I don't see the problem to describe it in text, like CSS is doing.

Clearly you have never actually written a QStyle. Something like Oxygen
involves *multiple* gradients just for the window background. Don't
forget inline SVG's for elements like the tree expanders and the 'icons'
on scroll bar buttons, combo boxes, spin boxes... and that's not even
the *hard* stuff.

Try specifying a tab bar in CSS. You have text margins, margins between
the tabs, possible complex shapes of the tabs themselves (all of which
need complicated gradients for shading)... The current version of the
Oxygen style (well, the KDE4 version anyway) represents *years* of work,
and even then I would not say it is perfect.

Take a look at
http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif and
explain to me how to replicate that in CSS. Start with the scroll bar
handle. *Then* I will believe you when you say there is no problem
describing widget style in CSS.

That said, there *is* a textual language that can be used to adequately
describe a style. That language is commonly known as "C++".

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

So you are writing a style for the QPaintEngine. What if you have a OpenGL back 
end or some other back ends where your descriptions does not fit that well any 
more? I have seen much more complicated things written in an abstract way, so 
it should be possible. And I haven't said that you should use CSS. Some custom  
DSL would quite handy. Actually I don't care about that fancy styles, they 
looks too baroque to me but I want something like Flatpak so I don't have work 
with outdated packages! But that are my priorities. [?]


From: Matthew Woehlke 
Sent: Thursday, November 24, 2016 5:36:04 PM
To: development@qt-project.org
Cc: Marco Bubke
Subject: Re: Basing Qt Creator Coding Style on C++ Core Guidelines?

On 2016-11-22 06:25, Marco Bubke wrote:
> On November 22, 2016 08:17:57 Thiago Macieira wrote:
>> Theming and styling is a complex operation. It's not just "propagating
>> values". Reading config files will at best get you the right font, correct 
>> icon
>> set, and somewhat correct colours. But gradients, shapes, complex dialogs 
>> will
>> not work.
>
> I don't see the problem to describe it in text, like CSS is doing.

Clearly you have never actually written a QStyle. Something like Oxygen
involves *multiple* gradients just for the window background. Don't
forget inline SVG's for elements like the tree expanders and the 'icons'
on scroll bar buttons, combo boxes, spin boxes... and that's not even
the *hard* stuff.

Try specifying a tab bar in CSS. You have text margins, margins between
the tabs, possible complex shapes of the tabs themselves (all of which
need complicated gradients for shading)... The current version of the
Oxygen style (well, the KDE4 version anyway) represents *years* of work,
and even then I would not say it is perfect.

Take a look at
http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif and
explain to me how to replicate that in CSS. Start with the scroll bar
handle. *Then* I will believe you when you say there is no problem
describing widget style in CSS.

That said, there *is* a textual language that can be used to adequately
describe a style. That language is commonly known as "C++".

--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
[snip]
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution.

Well, what about all the rest of applications? Your heavily used apps (and 
*libs*, don't forget them) are not necessarily other user's.

For what it's worth you can see in [qtbase.txt] a list of packages that would 
get removed from Debian if we where to remove qtbase right now. In other 
words, the list of apps and libs that would be affected by an ABI breackage.

You can also think on the amount of flatpacks you would need to make.

[qtbase.txt] 

-- 
lo cual parece incompatible.
lógica, esa tendrá particiones dentro,
si se transforma la extendida a
tiene particiones lógicas, luego
extendida. Una extendida
estar dentro de una partición
Una partición lógica necesita

Diga NO al topposting.

  Matias Silva Bustos

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 17:20:09 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > Now I have a question: how will the Qt community take that a distro
> > changes
> > the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes
> > happen?
> 
> We prefer to work with downstreams and have those changes in Qt itself. Not
> because we don't trust Debian, Fedora and OpenSUSE maintainers to do the
> right thing, but precisely because it's multiple teams. Why should each
> team redevelop the solution?

Ah, I was not clear enough, I was actually meaning this: having a solution 
pre-thought right from Qt itself. And yes, what you describe seems an 
excellent way to deal with this.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 11:25:45 PST Marco Bubke wrote:
> I don't see the problem to describe it in text, like CSS is doing. Actually
> it has the advantage to be independent of drawing systems. If you code it
> in C++ it is hard to translate that to OpenGL etc.

For 20 years we have had code do it. Doing it with text files is not tested, 
not a tried alternative.

> > And I don't see anyone volunteering for a major overhaul of QtWidget's
> > styling system. I don't even think a volunteer would be *accepted* by the
> > Qt Project.
> Why do you can not write a QStyle whicj is bridging it?

Yeah, I stand corrected. Maybe a style would be accepted by the Qt Project.

But I retain the statement that no one has tried to do a style as complex as 
Breeze or a platform integration without plugins. When we created the solution 
for platform themes in Qt 5.0, we went straight to the plugin solution. So we 
simply don't know how far we can get.

> Come on,  it is mostly broken for me already today. If you mix different
> toolkits it is not working that well. Mix High DPI in it and it gets worse.
> Linux Desktop is already in a ugly shape,  I don't see how it get worse
> with it.

That doesn't mean we should throw up our hands and make things even worse. We 
have the GTK3 theme, there's a Qt theme for GTK; Firefox, Chromium and 
OpenOffice have Qt/KDE integration too. For example, all of the applications[*] 
I use on a daily basis use a KDE file dialog for opening and saving files.

[*] the only exception is my self-built Qt Creator because it uses my self-
built, binary-incompatible Qt 5, but then I almost never use Ctrl+O, I just 
rely on Ctrl+K f to open files.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 22, 2016 08:17:57 Thiago Macieira  wrote:

> On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote:
>> So you say it it does not work because of themeing support? Isn't Qt
>> Controls 2 not anymore providing them too. And is there no technical
>> solutions for that? Like propagating the values to the Flatpack themeing
>> engine. This could be improve the interoperability between different
>> desktop libraries too. The implementation which is based on GTK or Qt is
>> suboptimal anyway. It shows visually why Linux Desktop was never widely
>> adopted. I mean the lack of cooperation and the hesitancy to try to
>> understand the context of the other. I use Linux all the day, but honestly
>> many things are broken, especially where Unix wasn't copied.
>
> So you're saying we need to develop another GUI toolkit for Linux desktops so 
> that we can share some common things between the existing toolkits?
>
> This comes to mind: https://xkcd.com/927/
>
> Theming and styling is a complex operation. It's not just "propagating 
> values". Reading config files will at best get you the right font, correct 
> icon 
> set, and somewhat correct colours. But gradients, shapes, complex dialogs 
> will 
> not work.

I don't see the problem to describe it in text, like CSS is doing. Actually it 
has the advantage to be independent of drawing systems. If you code it in C++ 
it is hard to translate that to OpenGL etc. 

> And I don't see anyone volunteering for a major overhaul of QtWidget's 
> styling 
> system. I don't even think a volunteer would be *accepted* by the Qt Project. 

Why do you can not write a QStyle whicj is bridging it? 

> So, no, there is no solution. Qt applications in a flatpak or similar will 
> not 
> look or feel native, therefore it is not an acceptable solution for an 
> application of regular use.

Come on,  it is mostly broken for me already today. If you mix different 
toolkits it is not working that well. Mix High DPI in it and it gets worse. 
Linux Desktop is already in a ugly shape,  I don't see how it get worse with 
it. 

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 05:59:24 PST Marco Bubke wrote:
> > I guess GTK maintainers suffer, specially with the last changes they
> > announced some time ago about breaking API/ABI (sorry, I don't remember
> > exactly which one) in some minor releases. Incindentally the first thing
> > we Qt maintainers though about those changes is how lucky we are to have
> > such a string-minded upstream that guarantess ABI during the life of a
> > major version.
> 
> So GTK maintainers can do it. There are much more applications on my Linux
> Desktop so it is possible. And like Linus Torvalds has said,  it is
> questionable to provide a package for every application on Earth. Flatpack
> is a much more reasonable choise for the developer and the user.

First of all, GTK maintainers haven't started doing their weird dance of ABI 
breakage. We don't know if they'll actually go through with it and, if they 
do, for how long they'll keep doing it. It's very likely that distributions 
(aside from GTK-centric Fedora) will not keep the unstable versions updated, 
so they'll get less testing. I find it highly likely the GTK developers abandon 
this weird dance before or during GTK 5 because of the mess they created.

I don't agree on the philosophy of the flatpaks and similar because they're 
based on a shifting foundation. Oh, it's ok to have a random app here and 
there that I barely ever use not follow the system L -- for example, the 
Intel Parallel Studio installer (a Qt 5.6 application). But the everyday 
applications must be native.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 07:00:17 PST Marc Mutz wrote:
> On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote:
> > That said, sometimes rebuilding even if there was no dependency on the
> > private  API could result in improvements. For example, every time we add
> > overloads there's a chance that the new method is faster and will get
> > selected.
> 
> Its even worse: if Qt fixes a bug in an inline function, no application will
> benefit unless recompiled, either. So for any Qt user, and esp. distros,
> not recompiling all users of Qt when Qt changes runs the risk of not
> getting some of the bug fixes, leading to users seeing those bugs together
> with Qt versions in which they're officially fixed.

True, but there are two important factors in this:

1) those bugfixes and overload additions are not so common

2) application rebuilding can happen at a leisure pace, when resources are 
available or when the application would have been updated anyway

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote:
> So you say it it does not work because of themeing support? Isn't Qt
> Controls 2 not anymore providing them too. And is there no technical
> solutions for that? Like propagating the values to the Flatpack themeing
> engine. This could be improve the interoperability between different
> desktop libraries too. The implementation which is based on GTK or Qt is
> suboptimal anyway. It shows visually why Linux Desktop was never widely
> adopted. I mean the lack of cooperation and the hesitancy to try to
> understand the context of the other. I use Linux all the day, but honestly
> many things are broken, especially where Unix wasn't copied.

So you're saying we need to develop another GUI toolkit for Linux desktops so 
that we can share some common things between the existing toolkits?

This comes to mind: https://xkcd.com/927/

Theming and styling is a complex operation. It's not just "propagating 
values". Reading config files will at best get you the right font, correct icon 
set, and somewhat correct colours. But gradients, shapes, complex dialogs will 
not work.

And I don't see anyone volunteering for a major overhaul of QtWidget's styling 
system. I don't even think a volunteer would be *accepted* by the Qt Project. 
So, no, there is no solution. Qt applications in a flatpak or similar will not 
look or feel native, therefore it is not an acceptable solution for an 
application of regular use.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kevin Kofler]

Marco Bubke wrote:

> On November 22, 2016 02:10:50 Thiago Macieira wrote:
>> GTK 2 and GTK 3 do keep their ABI just fine.
> 
> To my understanding GTK 3 gives no guarantees at all.

That is not true. GTK+ 3 is backwards ABI-compatible with previous versions 
all the way down to 3.0.

There are some private APIs whose ABI is not guaranteed, such as styling 
(where custom theme engines do not work anymore at all, you have to use CSS 
instead of C/C++ code now), but Qt also has such private APIs (and in fact 
Qt styling is also private, though I hope Qt will never break all existing 
styles the way GTK+ did!).

This will change with GTK+ 4 and their new way is going to be a nightmare, 
but I will draw a "Not My Problem" card and leave the Fedora GTK+ and GNOME 
packagers to deal with that. ;-)

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 22, 2016 00:47:26 Thiago Macieira  wrote:

> On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote:
>> I strongly agree with Andre'. And is a BC break in the time of flat pack
>> that bad? As an user I really looking forward to flat pack,  so I can
>> update my heavily used Applications and being not dependent on
>> distribution. This package could be much better optimize with LTO and
>> profile guided optimization. Maybe sharing everything is not that smart
>> anymore.
>
> FlatPaks don't work for Qt.
>
> Reasons:
>
> /usr/lib64/qt5/plugins/styles/breeze.so
> /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
>
> If you include Qt in your flatpak or equivalent, then your Qt application 
> will 
> not load the system plugins and will thus not have native look and feel in a 
> Plasma desktop or in LXQt.

So you say it it does not work because of themeing support? Isn't Qt Controls 2 
not anymore providing them too. And is there no technical solutions for that? 
Like propagating the values to the Flatpack themeing engine. This could be 
improve the interoperability between different desktop libraries too. The 
implementation which is based on GTK or Qt is suboptimal anyway. It shows 
visually why Linux Desktop was never widely adopted. I mean the lack of 
cooperation and the hesitancy to try to understand the context of the other. I 
use Linux all the day, but honestly many things are broken, especially where 
Unix wasn't copied.


> If you don't include Qt or if the included Qt loads plugins, then BC is 
> required.
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
> [snip] 
>> And how many applications are Qt only and use no standard lib anyway? Are
>> there any numbers?
>
> Good question, I wonder if there is a way to dig that.
>
>> Yes, sometimes they are inlined but sometimes they are
>> not. Is it really a so big burden for you? 
>
> Yes, as I described in a previous mail. Thiago got a nice word there: 
> bottleneck. It's a heck of a bottle neck.
>
>> And what are you doing about
>> GTK? To my knowledge their BC is quite limit.
>
> I guess GTK maintainers suffer, specially with the last changes they 
> announced 
> some time ago about breaking API/ABI (sorry, I don't remember exactly which 
> one) in some minor releases. Incindentally the first thing we Qt maintainers 
> though about those changes is how lucky we are to have such a string-minded 
> upstream that guarantess ABI during the life of a major version.

So GTK maintainers can do it. There are much more applications on my Linux 
Desktop so it is possible. And like Linus Torvalds has said,  it is 
questionable to provide a package for every application on Earth. Flatpack is a 
much more reasonable choise for the developer and the user. 


> -- 
> Bebe a bordo (pero con moderación)
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote:
> That said, sometimes rebuilding even if there was no dependency on the
> private  API could result in improvements. For example, every time we add
> overloads there's a chance that the new method is faster and will get
> selected.

Its even worse: if Qt fixes a bug in an inline function, no application will 
benefit unless recompiled, either. So for any Qt user, and esp. distros, not 
recompiling all users of Qt when Qt changes runs the risk of not getting some 
of the bug fixes, leading to users seeing those bugs together with Qt versions 
in which they're officially fixed.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 22, 2016 02:10:50 Thiago Macieira  wrote:

> On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor 
> Pérez Meyer wrote:
>> I guess GTK maintainers suffer, specially with the last changes they
>> announced some time ago about breaking API/ABI (sorry, I don't remember
>> exactly which one) in some minor releases. Incindentally the first thing we
>> Qt maintainers though about those changes is how lucky we are to have such
>> a string-minded upstream that guarantess ABI during the life of a major
>> version.
>
> GTK 2 and GTK 3 do keep their ABI just fine.

To my understanding GTK 3 gives no guarantees at all.

>
> Lisandro is talking about the GTK 4 plans. See 
> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kevin Kofler]

André Pönitz wrote:
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

The problem is that Qt is a very widely used library, and that it is also
used by many libraries used by other libraries used by other libraries, all
of which also use Qt directly (e.g. KF5-*). The "all of which also use Qt
directly" part is how this differs from something like libpng which is
usually only used through higher-level APIs. Most applications do not link
directly to libpng. (In fact, we do this:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n562
to avoid Qt applications needlessly linking directly to libpng etc. We
cannot do this with Qt because its APIs are used both directly and
transitively.)

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
> 
> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.

It is not *an* application. It is *many* libraries and applications.

> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

Well yes, testing is what our users do daily. What we need to take care of
is to not have broken dependencies (or worse, symbol lookup failures at
runtime because the ABI was changed without a soname bump). Otherwise, the
application will not run at all.

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

In Fedora, the issues this would cause are twofold:

1. In Rawhide, we would have to rebuild all packages using Qt, which are
   dozens, each time such a thing happens. But, due to the transitive
   dependency issue I mentioned at the beginning, they would have to be
   rebuilt in reverse dependency order. So we would first have to compute
   that. Our tools do not do it for us. The mass rebuilds Fedora release
   engineering does for some releases are always done in alphabetical order.
   That will not work if so many libraries have broken dependencies.

2. In Fedora, Qt is often updated to a newer version in a release, as an
   official update. And even when not, the newer version is typically
   offered in a Copr repository (a Fedora "PPA"). That would not be
   reasonably doable anymore if the new version were not binary-compatible.
   As in Debian's case, the packages (ab)using private APIs are already
   enough of an issue for us as it stands. But at least we have a list of
   those, and their interdependencies are limited, whereas rebuilding ALL
   packages using Qt would be orders of magnitude larger and not suitable
   for an update nor (realistically) even a Copr at all.

Major versions of Qt (i.e., 3, 4, 5, …) are the right place to change the
ABI, because there, we just make both versions coexist, and the transition
becomes relatively smooth. But also breaking binary compatibility in the
minor releases would not really scale.

> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.

But if our users were to be stuck at, say, Qt 5.8 because 5.9 would be
binary-incompatible, they would be losing much more features.

> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

You can always think about it, but if you do so, you will quickly find that
it is not practical at all.


Marco Bubke wrote:
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution. This package could be much better optimize with LTO and
> profile guided optimization. 

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

[Kevin Kofler]

Marc Mutz wrote:
> People make mistakes. The difference is that, in the STL, by way of a
> larger target audience, mistakes tend to be fewer than in Qt (looked at
> qtimageformats, lately?)

That is not a fair comparison. The STL has nothing comparable to 
qtimageformats. Image decoding and encoding is necessarily a low-level byte 
crunching task, and performance-critical, even. And thus, things such as 
buffer overflows can happen. The STL just leaves you in the cold if you need 
to do any kind of image processing.

> If Qt consistently did a better job at implementing such things, the world
> might be different. But looking at the Qt containers, and the Qt image
> format plugins, I'd much rather use an external library (STL,
> lib{jpeg,png,tiff,...) that everyone else also uses, than to reinvent the
> wheel and create bugs exclusive to Qt.

Several of the decoders already use such external libraries. (The
qt5-qtimageformats distribution package I use is linked to libjasper.so.1, 
libmng.so.2, libtiff.so.5 and libwebp.so.6.) It might make sense to port the 
others to those libraries. But using an external library does not 
necessarily fix all problems. Those libraries can have security 
vulnerabilities (buffer overflows, integer overflows etc.) too. And 
sometimes, the library you chose is not or poorly maintained. And finally, 
there can also be bugs in the way the library is called in your code. Still, 
it is usually a better approach than hardcoding the format directly in Qt.

Now, if you are suggesting that all the applications should just use the 
low-level libraries directly, that is not a reasonable suggestion. Those 
libraries typically have very low-level C APIs. And most importantly, you 
need to use a different library for every single format! That is what 
higher-level abstractions such as qtimageformats are for.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 17:07:08 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > > I remember in the MeeGo days when building MeeGo with OBS spent an hour
> > > on
> > > a very beefy machine compiling Qt, with most of the resources in the OBS
> > > farm unused because nothing else could be built yet. With Qt 5 and our
> > > split packages, this lessens because only qtbase is the bottleneck.
> > 
> > As long as qtbase's private headers do not change. I guess in that case
> > one
> > who knows exactly what would affect will just rebuild the necessary parts,
> > the rest of us need to get all the stuff rebuilt (17 submodules? maybe
> > they
> > are more right now).
> 
> My point is that there are packages that depend only on qtbase libraries, so
> they can start rebuilding as soon as qtbase is done, while the system is
> building qtsvg and qtserialport in another node in the farm. And this
> scenario was the "rebuild world" case, regardless of whether there were ABI
> breakages or not.
> 
> You're right that if you're rebuilding only what needs to be rebuilt, then
> an update to qtbase should trigger only rebuilding of packages that
> depended on the private API. With the ELF version marker, that should be
> easy to detect now.

Just for the record, every time that qtbase's private symbols change we end up 
requiring a rebuild of almost all the submodules. We might be able to do 
better with some more hacks, but as we normally require this when we are 
pushing a new upstream release there is currently not much of a point.

> That said, sometimes rebuilding even if there was no dependency on the
> private API could result in improvements. For example, every time we add
> overloads there's a chance that the new method is faster and will get
> selected.

Fair point.

[snip]
> And ELF symbol versioning. That allows both libraries to be loaded into
> memory and not interfere with each other, so long as you don't pass data
> from one to the other.

Indeed, that would really be great.

-- 
Simulations are not data. In God we trust, all the others must supply data.
 Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments,
 http://www.spectrum.ieee.org/nov04/4004

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> Now I have a question: how will the Qt community take that a distro changes
> the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes
> happen?

We prefer to work with downstreams and have those changes in Qt itself. Not 
because we don't trust Debian, Fedora and OpenSUSE maintainers to do the right 
thing, but precisely because it's multiple teams. Why should each team 
redevelop the solution?

And don't forget tiny distros and self-built distros (Yocto comes to mind!) 
whose teams are not aware of those changes.

Note that we can do ABI versioning if we wanted to:

libQt5Core.so.5
 ↑↑
 ❘⌞→ ABI (binary) version
 ⌞→ API (source) version

The ELF symbol version would need to be adapted too. Right now, it marks 
everything as "Qt_5".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> I guess GTK maintainers suffer, specially with the last changes they
> announced some time ago about breaking API/ABI (sorry, I don't remember
> exactly which one) in some minor releases. Incindentally the first thing we
> Qt maintainers though about those changes is how lucky we are to have such
> a string-minded upstream that guarantess ABI during the life of a major
> version.

GTK 2 and GTK 3 do keep their ABI just fine.

Lisandro is talking about the GTK 4 plans. See 
https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> > I remember in the MeeGo days when building MeeGo with OBS spent an hour on
> > a very beefy machine compiling Qt, with most of the resources in the OBS
> > farm unused because nothing else could be built yet. With Qt 5 and our
> > split packages, this lessens because only qtbase is the bottleneck.
> 
> As long as qtbase's private headers do not change. I guess in that case one
> who knows exactly what would affect will just rebuild the necessary parts,
> the rest of us need to get all the stuff rebuilt (17 submodules? maybe they
> are more right now).

My point is that there are packages that depend only on qtbase libraries, so 
they can start rebuilding as soon as qtbase is done, while the system is 
building qtsvg and qtserialport in another node in the farm. And this scenario 
was the "rebuild world" case, regardless of whether there were ABI breakages 
or not.

You're right that if you're rebuilding only what needs to be rebuilt, then an 
update to qtbase should trigger only rebuilding of packages that depended on 
the private API. With the ELF version marker, that should be easy to detect 
now.

That said, sometimes rebuilding even if there was no dependency on the private 
API could result in improvements. For example, every time we add overloads 
there's a chance that the new method is faster and will get selected.

> > I can't think of anything that would be worth the major headache that
> > breaking BC more often than once every 4 years would cause. And note I'm
> > not talking about breaking SC.
> 
> And if this can be coupled with an upstream-made SONAME like 5 to 5abi1...
> well, I guess once in 4 years is not that much.

And ELF symbol versioning. That allows both libraries to be loaded into memory 
and not interfere with each other, so long as you don't pass data from one to 
the other.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 21:21:08 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
[snip]
> A transition like that would definitely take like a month, in which no other
> transition will probably be able to happen because Qt is *so* widely used.

Maybe worth mentioning: in order to improve the speed of a transition no Qt-
based apps/libs will be able to be upsdated during the process *except* when 
they fix bugs in order to achieve the transition. That includes the whole KDE 
stack, apart from Qt-only things.

-- 
Un viejo proverbio de El.Machi dice que la memoria es como
las papas fritas... ¡nunca sobran!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 15:57:06 ART Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote:
> > I also said that packagers (i.e. people like you) *are* affected, but I
> > claimed the way they are affected is not fundamentally different from
> > what happens if the packages in question uses any other library that
> > doesn't guarantee BC, or - in case they have similar BC promises like Qt
> > - what happens when there are jumps in major versions.
> 
> Fundamentally, no. But the important difference is the bottleneck.
> 
> I remember in the MeeGo days when building MeeGo with OBS spent an hour on a
> very beefy machine compiling Qt, with most of the resources in the OBS farm
> unused because nothing else could be built yet. With Qt 5 and our split
> packages, this lessens because only qtbase is the bottleneck.

As long as qtbase's private headers do not change. I guess in that case one 
who knows exactly what would affect will just rebuild the necessary parts, the 
rest of us need to get all the stuff rebuilt (17 submodules? maybe they are 
more right now).
 
[snip]
> I can't think of anything that would be worth the major headache that
> breaking BC more often than once every 4 years would cause. And note I'm
> not talking about breaking SC.

And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... 
well, I guess once in 4 years is not that much.

-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
[snip] 
> And how many applications are Qt only and use no standard lib anyway? Are
> there any numbers?

Good question, I wonder if there is a way to dig that.

> Yes, sometimes they are inlined but sometimes they are
> not. Is it really a so big burden for you? 

Yes, as I described in a previous mail. Thiago got a nice word there: 
bottleneck. It's a heck of a bottle neck.

> And what are you doing about
> GTK? To my knowledge their BC is quite limit.

I guess GTK maintainers suffer, specially with the last changes they announced 
some time ago about breaking API/ABI (sorry, I don't remember exactly which 
one) in some minor releases. Incindentally the first thing we Qt maintainers 
though about those changes is how lucky we are to have such a string-minded 
upstream that guarantess ABI during the life of a major version.

-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 15:42:12 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > > So how often do you had a BC break in stdlibc++?
> > 
> > Last time was with gcc5.
> 
> In other words, once in 11 years.
> 
> > And quite messy in some concerns too because they did not increase the
> > SONAME
> > as they should, so the only thing we had is to track which apps/libs got
> > rebuilt. Normally we can track this with a proper SONAME change.
> 
> Because GCC developers, like the proponents of inline namespaces, forget
> that libraries use their libraries and thus expose their ABI differences in
> their ABI. GCC devs invented the "abi_tag" attribute so they could mark
> methods according to a deveoper-defined tag, and propagate that tag. They
> provide both sets of ABIs in libstdc++.
> 
> But unless developers of downstream libraries take the precautions to
> provide them both in their own libraries, this causes a BC breakage. THAT
> was the issue.

Point taken. If the 3rd party exposed API does not changes that much and the 
necessary guards are in place then it should not hurt that frequently.

Now I have a question: how will the Qt community take that a distro changes 
the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes 
happen?

-- 
Only wimps use tape backup: real men just upload their important stuff on
ftp, and let the rest of the world mirror it ;)
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 22 de noviembre de 2016 01:06:00 ART André Pönitz wrote:
> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> > [snip]
> > 
> > > - people using Qt in applications distributed by packaging
> > > 
> > >   systems (read "Linux distributions"). They are not affected
> > >   by BC breakages.
> > 
> > Users might not notice if we maintainers have to deal with this nightmare.
> 
> That's what I said.
> 
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.
> 
> > If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
> > lib break ABI we need to get Qt rebuilt and *everything* building
> > against it.
> 
> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden

Because it's not just a few applications nor a few archs nor a day or two of 
rebuilding stuff nor Qt alone.

Let's take for example the work we Debian maintainers need to do on every 
minor Qt update due to private symbols.

As you all should know Qt ships private headers which should only be used by 
Qt itself. But there are people out there that need to use those private 
headers in order to be able to, for example, provide a native theme.

Of course Qt will not bump SONAME and that's fine by definition, because they 
are private headers. But we maintainers need to deal with it somehow.

One way to achieve it will mean rebuilding the whole set of apps using Qt, but 
that's definitely too much. Using something we call "symbols files" we where 
able to first hack a way to determine which apps uses private symbols (and 
then thanks to Thiago providing us with tagged symbols we improved it quite a 
lot). So we get down to something like this:



Of course that only shows 2 out of the 11 archs we have.

It will seem a pretty easy list, most of it being Qt submodules. That alone on 
the best case scenario takes us 3 to 5 days.

Last time we did it it got tangled with an openssl transition as both of them 
needed to rebuild the same package: calibre. It took us more than a week to 
solve the issue, but hey, it's what packagers do :-) (sadly not for a living 
;-) )

Now if you break BC at, let's say, libqt5core5 we would need to rename it to 
something like libqt5core5abi1 and rebuild the whole stack of stuff using Qt. 
The list of the example above would probably crawl to level 7 with quite some 
more packages on each level.

A transition like that would definitely take like a month, in which no other 
transition will probably be able to happen because Qt is *so* widely used.

> while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
> 
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

No.
 
> > That's the worth nightmare we distro maintainers can dream
> > on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

As I described above: by stopping half a distribution to be updated by too 
much time.

> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.

We know and do understand this. But the side effects that it ships are not 
negligible too. We would suffer a lot from them.

-- 
Un viejo proverbio de El.Machi dice que la memoria es como
las papas fritas... ¡nunca sobran!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote:
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

Fundamentally, no. But the important difference is the bottleneck.

I remember in the MeeGo days when building MeeGo with OBS spent an hour on a 
very beefy machine compiling Qt, with most of the resources in the OBS farm 
unused because nothing else could be built yet. With Qt 5 and our split 
packages, this lessens because only qtbase is the bottleneck.

> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.

Again, a matter of scale. And note you said "rebuilding an application", not 
"rebuilding all KF5 and other domain libraries, then the application".

In addition, the ability to upgrade just Qt and then retest already-built 
libraries and applications allows us and distros to detect regressions and 
other issues. There's no need to rebuild everything in order to see what 
happens.

> > That's the worth nightmare we distro maintainers can dream
> > on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

End users who don't develop, sure. 

If they develop something, then their self-built libraries will break and need 
to be rebuilt. I've since stopped building KDE from sources, but that used to 
be a problem with libraries that broke ABI. ICU and Boost come to mind: after 
a system upgrade, many applications would fail to load (to the point of not 
having a desktop at all) because the older versions of the system packages for 
those libs got removed in the system upgrade until I rebuilt the world. 
Granted, this can be fixed by not removing those packages during system 
upgrade.

> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I can't think of anything that would be worth the major headache that breaking 
BC more often than once every 4 years would cause. And note I'm not talking 
about breaking SC.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote:
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution. This package could be much better optimize with LTO and
> profile guided optimization. Maybe sharing everything is not that smart
> anymore.

FlatPaks don't work for Qt.

Reasons:

/usr/lib64/qt5/plugins/styles/breeze.so
/usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so

If you include Qt in your flatpak or equivalent, then your Qt application will 
not load the system plugins and will thus not have native look and feel in a 
Plasma desktop or in LXQt.

If you don't include Qt or if the included Qt loads plugins, then BC is 
required.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> > So how often do you had a BC break in stdlibc++?
> 
> Last time was with gcc5.

In other words, once in 11 years.

> And quite messy in some concerns too because they did not increase the
> SONAME
> as they should, so the only thing we had is to track which apps/libs got
> rebuilt. Normally we can track this with a proper SONAME change.

Because GCC developers, like the proponents of inline namespaces, forget that 
libraries use their libraries and thus expose their ABI differences in their 
ABI. GCC devs invented the "abi_tag" attribute so they could mark methods 
according to a deveoper-defined tag, and propagate that tag. They provide both 
sets of ABIs in libstdc++.

But unless developers of downstream libraries take the precautions to provide 
them both in their own libraries, this causes a BC breakage. THAT was the 
issue.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 21, 2016 23:57:07 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
>> [snip]
>> > - people using Qt in applications distributed by packaging
>> >   systems (read "Linux distributions"). They are not affected
>> >   by BC breakages.
>> 
>> Users might not notice if we maintainers have to deal with this nightmare.
>
> That's what I said.
>
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

And how many applications are Qt only and use no standard lib anyway? Are there 
any numbers? Yes, sometimes they are inlined but sometimes they are not. Is it 
really a so big burden for you? And what are you doing about GTK? To my 
knowledge their BC is quite limit. 

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
>
> I understand that.
>
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
>
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

You can capture behavior changes by unit and integration tests but there is 
always the possibility that you break something because the complexity is not 
reasonable testable. It's always a tradeoff. 

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
>
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?
>
> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.
>
> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I strongly agree with Andre'. And is a BC break in the time of flat pack that 
bad? As an user I really looking forward to flat pack,  so I can update my 
heavily used Applications and being not dependent on distribution. This package 
could be much better optimize with LTO and profile guided optimization. Maybe 
sharing everything is not that smart anymore. 

> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> [snip]
> > - people using Qt in applications distributed by packaging
> >   systems (read "Linux distributions"). They are not affected
> >   by BC breakages.
> 
> Users might not notice if we maintainers have to deal with this nightmare.

That's what I said.

I also said that packagers (i.e. people like you) *are* affected, but I
claimed the way they are affected is not fundamentally different from
what happens if the packages in question uses any other library that
doesn't guarantee BC, or - in case they have similar BC promises like Qt
- what happens when there are jumps in major versions.

> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
> lib break ABI we need to get Qt rebuilt and *everything* building
> against it.

I understand that.

What I do not understand is how rebuilding an application can be
considered a significant burden while running a full test cycle (Qt
doesn't guarantee behavioural compatibility between versions, any
versions for that matter) is not.

I fear that the answer is something along the lines of "we
might run a smoke test, but no more", isn't it?

> That's the worth nightmare we distro maintainers can dream
> on. And yes, we would need to adjust Qt's SONAME on each change.

That's maybe one per year. With a typical distro running, say, two
bigger updates per year replacing most packages anyway, that would
ill-affect a distro user... how?

I am not here trying to make your life harder. I do understand that you
would be on the receiving end in case Qt BC guarantees are lowered. I
believe I understand the effort packagers invest, and the benefit this
has for the Qt ecosystem. But the BC guarantee comes at quite some
price like the inability to fix certain mistakes that slipped into some
x.0 release, or to use certain features that only became usable a some
x.5 time, and this price is payed both by developers and end users.

This is not a zero-sum game, there's room for total improvement, and
since BC is not the only thing packagers care for a loss of BC could
possibly get compensated by something dev can influence. At the very
least I see no reason to forbid thinking about it.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 19:36:43 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
> On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote:
> > So how often do you had a BC break in stdlibc++?
> 
> Last time was with gcc5. We've got a nice big [transition] within Debian due
> to it. It was related to C++11 stuff, and we've got away precisely because
> Qt doesn't expose it.

Forgot to mention: begginging of 2016 if I remember correctly.

-- 
La ciencia sin la religión es renga, la religión sin la ciencia es ciega.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote:
> So how often do you had a BC break in stdlibc++?

Last time was with gcc5. We've got a nice big [transition] within Debian due 
to it. It was related to C++11 stuff, and we've got away precisely because Qt 
doesn't expose it.

And quite messy in some concerns too because they did not increase the SONAME 
as they should, so the only thing we had is to track which apps/libs got 
rebuilt. Normally we can track this with a proper SONAME change.

[transition] the required work to get stuff rebuilt against a lib changing 
SONAME (or breaking ABI without changing it) in the whole Debian archive and 
let the affected packages migrate to testing in the same go.

-- 
The generation of random numbers is too important to be left to chance.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alejandro Exojo]

On Saturday 19 November 2016 21:08:00 Kevin Kofler wrote:
> I am glad that I am not alone with that feeling.
> 
> And by the way, with my distribution packager hat on, I have to frown upon
> the idea of dragging in yet another dependency just to enforce the C++
> language inventor's personal, not uncontroversial stylistic preferences.

Have you seen the size of the GSL? I think I skimmed in one go through all the 
source code when it was published, and I did it while commuting, on a mobile 
phone. Maybe it's a tad larger now, but according to Mark's comment, stuff 
like owner could even be bundled/reimplemented.

I'm almost always on the side that would not like Qt to change at all if it's 
to make it similar to the standard library API, but I've always had in the 
mental to-do list some patch to Qt that would annotate when ownership of 
QObjects is transferred ("I guess the QNetworkReply returned by QNAM::post has 
a parent, because the docs don't say it should be deleted... Or should be?").

I though that qdoc would be the tool for this (like we have \threadsafe) but 
stuff like owner<> and not_null<> are IMHO vastly superior. And at least they 
chose reasonable names for these. :)

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

So how often do you had a BC break in stdlibc++? 


On November 21, 2016 19:50:23 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> [snip]
>> - people using Qt in applications distributed by packaging
>>   systems (read "Linux distributions"). They are not affected
>>   by BC breakages.
>
> Users might not notice if we maintainers have to deal with this nightmare.
>
> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib 
> break 
> ABI we need to get Qt rebuilt and *everything* building against it. That's 
> the 
> worth nightmare we distro maintainers can dream on. And yes, we would need to 
> adjust Qt's SONAME on each change.
>
> -- 
> Yo quiero conocer el pensamiento de Dios, el resto son detalles.
>  Albert Einstein
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
[snip]
> - people using Qt in applications distributed by packaging
>   systems (read "Linux distributions"). They are not affected
>   by BC breakages.

Users might not notice if we maintainers have to deal with this nightmare.

If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib break 
ABI we need to get Qt rebuilt and *everything* building against it. That's the 
worth nightmare we distro maintainers can dream on. And yes, we would need to 
adjust Qt's SONAME on each change.

-- 
Yo quiero conocer el pensamiento de Dios, el resto son detalles.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 21 November 2016 09:37:38 Philippe wrote:
> > And you think Qt provides what MS added to std::vector here, in QVector?
> 
> Of course not. I just point the danger of dependencies on the usage of STL
> APIs, especially corner APIs.
> 
> I understand the #1 target of Qt is to behave the same on all platforms
> (as much as possible...). This is what users expects, at least.

These fixes mostly sound like they were enabled by - finally - implementing 
missing core C++11 features. We know we can't rely on MS to provide all C++11 
features atm, so we know not to rely on std::vector using 
std::move_if_noexcept, e.g., too. The aliasing thing, though, sounds like a 
genuine bug, and GCC's nth_element was buggy for some time, too.

OTOH, QList does not at all behave the same on different platforms, 
either, in a much more fundamental way than any std::vector behaviour differs 
between platforms these days.

People make mistakes. The difference is that, in the STL, by way of a larger 
target audience, mistakes tend to be fewer than in Qt (looked at 
qtimageformats, lately?), and more easily fixed, because of largely no BC 
support, so it seems a bit skewed to throw one such STL bug on the table as an 
argument not to use the STL.

If Qt consistently did a better job at implementing such things, the world 
might be different. But looking at the Qt containers, and the Qt image format 
plugins, I'd much rather use an external library (STL, lib{jpeg,png,tiff,...) 
that everyone else also uses, than to reinvent the wheel and create bugs 
exclusive to Qt.

Thanks,
Marc

> Philippe
> 
> On Mon, 21 Nov 2016 09:04:59 +0100
> 
> Marc Mutz  wrote:
> > On Sunday 20 November 2016 23:20:11 Philippe wrote:
> > > On Sun, 20 Nov 2016 19:49:09 +0100
> > > 
> > > Marc Mutz  wrote:
> > > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL,
> > > > but failed to take advantage of the STL containers,
> > > 
> > > ...good that STL containers were not used... Look at _this month_
> > > Visual Studio 2017 announcement:
> > > 
> > > 
> > > std::vector has been overhauled for correctness and performance:
> > > aliasing during insertion/emplacement is now correctly handled as
> > > required by the Standard, the strong exception guarantee is now
> > > provided when required by the Standard via move_if_noexcept() and
> > > other logic, and
> > > insertion/emplacement perform fewer element operations.
> > > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> > > 
> > > 
> > > Being the "standard library" does not mean "bug free and equal on all
> > > platforms". Dependencies with other libraries must be careful checked.
> > 
> > And you think Qt provides what MS added to std::vector here, in QVector?
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Philippe]

> And you think Qt provides what MS added to std::vector here, in QVector?

Of course not. I just point the danger of dependencies on the usage of STL APIs,
especially corner APIs.

I understand the #1 target of Qt is to behave the same on all platforms
(as much as possible...). This is what users expects, at least.

Philippe

On Mon, 21 Nov 2016 09:04:59 +0100
Marc Mutz  wrote:

> On Sunday 20 November 2016 23:20:11 Philippe wrote:
> > On Sun, 20 Nov 2016 19:49:09 +0100
> > 
> > Marc Mutz  wrote:
> > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but
> > > failed to take advantage of the STL containers,
> > 
> > ...good that STL containers were not used... Look at _this month_ Visual
> > Studio 2017 announcement:
> > 
> > 
> > std::vector has been overhauled for correctness and performance: aliasing
> > during insertion/emplacement is now correctly handled as required by the
> > Standard, the strong exception guarantee is now provided when required by
> > the Standard via move_if_noexcept() and other logic, and
> > insertion/emplacement perform fewer element operations.
> > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> > 
> > 
> > Being the "standard library" does not mean "bug free and equal on all
> > platforms". Dependencies with other libraries must be careful checked.
> 
> And you think Qt provides what MS added to std::vector here, in QVector?
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Sunday 20 November 2016 23:20:11 Philippe wrote:
> On Sun, 20 Nov 2016 19:49:09 +0100
> 
> Marc Mutz  wrote:
> > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but
> > failed to take advantage of the STL containers,
> 
> ...good that STL containers were not used... Look at _this month_ Visual
> Studio 2017 announcement:
> 
> 
> std::vector has been overhauled for correctness and performance: aliasing
> during insertion/emplacement is now correctly handled as required by the
> Standard, the strong exception guarantee is now provided when required by
> the Standard via move_if_noexcept() and other logic, and
> insertion/emplacement perform fewer element operations.
> (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> 
> 
> Being the "standard library" does not mean "bug free and equal on all
> platforms". Dependencies with other libraries must be careful checked.

And you think Qt provides what MS added to std::vector here, in QVector?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Philippe]

On Sun, 20 Nov 2016 19:49:09 +0100
Marc Mutz  wrote:

> I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but 
> failed to take advantage of the STL containers,

...good that STL containers were not used... Look at _this month_ Visual
Studio 2017 announcement:


std::vector has been overhauled for correctness and performance: aliasing 
during insertion/emplacement is now correctly handled as required by the 
Standard, the strong exception guarantee is now provided when required by the 
Standard via move_if_noexcept() and other logic, and insertion/emplacement 
perform fewer element operations.
(https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)


Being the "standard library" does not mean "bug free and equal on all
platforms". Dependencies with other libraries must be careful checked.

Philippe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em domingo, 20 de novembro de 2016, às 19:49:09 PST, Marc Mutz escreveu:
> which Qt3D freely uses,
> now, in something called "assimp"

You mean the worst offender of warnings and code quality issues inside Qt? 
Sorry, that's not a good example and doesn't support your cause.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Sunday 20 November 2016 12:53:11 André Pönitz wrote:
> 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.

Right. I wasn't going to attack the BC promise on such a fundamental level, 
but I agree that its value is limited in a world where not even the compiler 
vendors can agree on a platform's C++ ABI.

I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but 
failed to take advantage of the STL containers, with 5.2, when Q_STRINGTABLE 
missed to be merged because it dared to use Boost (which Qt3D freely uses, 
now, in something called "assimp"), and now with the GSL, which promises much 
stronger statig type-checking because the new vocabulary types can be used to 
decalre intend much better, ... With each of these, and probably more, the 
pendulum swings more into the direction of more harm than good for Qt as a 
project. As a consequence, I'm advocating at least reverting the BC guarantees 
to their old meaning of "two versions of Qt are BC if, for a given platform, 
compiler, and set of dependencies, one Qt compiled against these can be 
replaced by the other without breaking code compiled against the former".

There are so many knobs to turn that make two C++ compilates binary 
incompatible, from ms-compatible bitfields, fortran-compatible double 
alignment, to compiler and standard library versions, that for any library to 
try to draw through that messy jungle a line labelled "this is where Qt BC 
begins" is just a logically nonsensical endeavour.

Sometimes, it's just better to compile separate library versions.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em domingo, 20 de novembro de 2016, às 08:33:23 PST, Marc Mutz escreveu:
> > Those parts of KDE don't keep BC guarantees. Distros have to rebuild
> > everything when their dependencies change.
> 
> I wonder why we used d-pointers and virtual_hook in, say, libkdepim if it
> doesn't guarantee BC...

There's a difference between breaking BC when Boost is upgraded and in every 
single patch release and even applied bugfix patch.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

On Sat, Nov 19, 2016 at 10:44:19PM +0100, Giuseppe D'Angelo wrote:
> On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke  wrote:
> I'm terribly sad that this thread has been derailed in an unrelated
> discussion.

Asking about Creator and BC on @dev was a perfect attempt at trolling
as far as I can tell.
 
> Please, could we all *stop* doing that and let's discuss that (*extremely
> important*) matter on another thread.
> 
> Staying on track: I would love to see (again) Creator as a playground for
> how well the GSL can be integrated into a Qt project.

For me it still is one of the main reasons to have Qt Creator at all,
and I still think it serves this purpose well in practice.

For the concrete matter of owner I *personally* see not much a reason
to have it, as for some reason I seemingly rarely ever run into those
unclear ownerships of naked T* and consequently don't understand where
all this hatred comes from. But then, owner is as non-intrusive as
it gets, and since I have a couple of '// owned' or '// not owned'
comments in my code it looks like having that compiler-checkable would
actually make sense. So I would not oppose using owner in Creator
code.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

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'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 19 November 2016 22:30:51 Thiago Macieira wrote:
> Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu:
> > You see, this is a perfect example of why we _don't_.
> >
> > 
> >
> > (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or
> > even 3). It hasn't been a problem for KDE to keep BC guarantees
> > comparable to what Qt does. What makes you think that Qt would be any
> > different?
> 
> Those parts of KDE don't keep BC guarantees. Distros have to rebuild 
> everything when their dependencies change.

I wonder why we used d-pointers and virtual_hook in, say, libkdepim if it 
doesn't guarantee BC...

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke  wrote:

> Hi
>
>
> This is a Qt Creator topic only so sorry to disturb every body else.
>
>
> Like you maybe have learned there are C++ Core Guidelines. They are
> already very comprehensive. What about basing the Qt Creator Code Style on
> it?
>
>
> I see advantages like new developer can easier grasp out rules because
> they are already familiar with it.
>
> We may have to exclude some rules too because they don't fit to us.
>

I'm terribly sad that this thread has been derailed in an unrelated
discussion.

Please, could we all *stop* doing that and let's discuss that (*extremely
important*) matter on another thread.

Staying on track: I would love to see (again) Creator as a playground for
how well the GSL can be integrated into a Qt project. Apart from owner,
have you identified some other guideline that you think it might be useful
for everyone?

Thanks,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu:
> You see, this is a perfect example of why we _don't_.
> 
> (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or even
> 3). It hasn't been a problem for KDE to keep BC guarantees comparable to
> what Qt does. What makes you think that Qt would be any different?

Those parts of KDE don't keep BC guarantees. Distros have to rebuild 
everything when their dependencies change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

19.11.2016, 09:46, "Marc Mutz" :
> On Saturday 19 November 2016 02:17:27 Konstantin Tokarev wrote:
>>  > If we do nothing else, we should at least use owner whereever
>>  > possible.
>>
>>  Wouldn't it be a better idea to use standard language feature to indicate
>>  ownership, i.e. std::unique_ptr, wherever it makes sense?
>
> Yes, if we could. But BC (see above) and SC will make this impossible for a
> long time to come.

IIRC Qt Creator keeps BC and SC compatibility only between patch releases, so
there is no real urge to introduce surrogate types instead of migration to
std::unique_ptr

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

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Philippe]

On Sat, 19 Nov 2016 21:08 +0100
Kevin Kofler  wrote:

> Alexander Nassian wrote:
>>  In my personal opinion I don't care much about BC but I'm happy that it 
>> blocks
> > STL usage because its brutally unnatural and I stumbled so often over
> > different behaviors of it on different platforms and compilers that I have
> > a real hate on the STL.
> 
> I am glad that I am not alone with that feeling.

+1

Philippe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 19 November 2016 14:18:20 Иван Комиссаров wrote:
> Still, we need those guarantees not to rebuild whole KDE packages in linux
> distros each time new Qt version (or new stdlib version if we’ll support
> std:: in API) is released (also, users should reinstall those packages
> too)

You see, this is a perfect example of why we _don't_.

(Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or even 3). 
It hasn't been a problem for KDE to keep BC guarantees comparable to what Qt 
does. What makes you think that Qt would be any different?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sábado, 19 de novembro de 2016, às 13:07:04 PST, Marc Mutz escreveu:
> As soon as someone explains to me what the material difference is between a)
> supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting
> mixing release and debug runtimes on Windows,

libc++ and libstdc++ are designed to interoperate, because they share operator 
new, std::exception and the base typeinfos, if compiled properly[*]. That 
means memory new'ed with one can be delete'd in the other, exceptions thrown 
in one can be caught in the other, dynamic casts work, etc.

The MSVC CRTs are currently not designed to interoperate. Not only do they 
each have their own operator new, one's delete cannot delete the other's 
pointers. That said, we *could* build a debug mode Qt against the release 
runtime (-Od -MT), we just don't. It's one of those "it was like that when I 
arrived" problems of Qt 4.0, though I helped fix the Unix debug/release problem 
for 4.2.

Another reason is that no one deploys debug-mode. So there's little danger of 
mixing because it doesn't happen in customers' hands. And then there's the 
fact that MS keeps breaking BC if you change the compiler, so anyone using 
MSVC needs to be careful anyway to avoid polluting one build with plugins from 
another, something that elsewhere is permitted. Just think of how pointless 
our discussion on whether we should upgrade our packaging system to MSVC 2015 
Update 3 or not...

Finally, MS has said it will start keeping binary compatibility with Visual 
Studio 2017 onwards (or was it 2015 onwards?), so this is actually a good time 
to revisit this.

[*] Apple compiles them properly. I have yet to see someone compiling them 
properly on Linux.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sábado, 19 de novembro de 2016, às 13:00:58 PST, Marc Mutz escreveu:
> That's how this came up: it prevents the use of the GSL in Qt

And as Marco points out, this thread is NOT about GSL in Qt. It's about 
(maybe) GSL in Qt Creator.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sábado, 19 de novembro de 2016, às 10:34:36 PST, Alexander Nassian 
escreveu:
> Will there be now 10 BC discussions every year?

No, that's why we need a QUIP for it so that we don't rediscuss it every year, 
unless the circumstances change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Иван Комиссаров]

IMO, we can mix libc++/libstd because we have some BC guarantees, not we have 
BC guarantees because we *need* to mix them. There’s no real difference between 
debug/release and libc++/libstd.
Still, we need those guarantees not to rebuild whole KDE packages in linux 
distros each time new Qt version (or new stdlib version if we’ll support std:: 
in API) is released (also, users should reinstall those packages too)

Иван Комиссаров

19 нояб. 2016 г., в 15:07, Marc Mutz  написал(а):

> As soon as someone explains to me what the material difference is between a) 
> supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting 
> mixing release and debug runtimes on Windows, I'm open for discussing the 
> merits of the former. Until then, I refuse to see a difference between the 
> two, refuse to accept that we need to support one and not the other, and 
> suggest to just compile two versions of Qt: libQt5*Foo-libc++.so and 
> libQt5*Foo-libstdc++.so. If this solves the problem on Windows, someone needs 
> to explain to me why it's not an option on Unix.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 19 November 2016 10:22:18 Иван Комиссаров wrote:
> Maybe we should start another thread about BC?
> I'm not convinced that MacOS is the only system when mixing libc++/stdlib
> makes sence. On linux you can do the same.

As soon as someone explains to me what the material difference is between a) 
supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting 
mixing release and debug runtimes on Windows, I'm open for discussing the 
merits of the former. Until then, I refuse to see a difference between the 
two, refuse to accept that we need to support one and not the other, and 
suggest to just compile two versions of Qt: libQt5*Foo-libc++.so and 
libQt5*Foo-libstdc++.so. If this solves the problem on Windows, someone needs 
to explain to me why it's not an option on Unix.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 19 November 2016 10:34:36 Alexander Nassian wrote:
> Will there be now 10 BC discussions every year?

No, just one for each time Qt suffers more from this policy. :)

That's how this came up: it prevents the use of the GSL in Qt. The STL was 
really just for simile. This is about the GSL.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Иван Комиссаров]

The problem is that Qt stuck at some point.
We can’t use STL in our API, so we forced to have QVector, …, QSharedPointer, 

On the other hand, we doesn’t develop those classes, because stl already have 
them. So, we’re missing QUniquePtr, qMakeShared, append(T&&) (yeah, COW, i 
know) and so on. 
We have to move from that point somewhere, either extending our classes to make 
them standard-compatible (when possible) or replace them with stl ones.

Иван Комиссаров

19 нояб. 2016 г., в 12:34, Alexander Nassian  
написал(а):

> Will there be now 10 BC discussions every year? At least it feels like. Why 
> can't it be decided and then accepted by everyone as is? In my personal 
> opinion I don't care much about BC but I'm happy that it blocks STL usage 
> because its brutally unnatural and I stumbled so often over different 
> behaviors of it on different platforms and compilers that I have a real hate 
> on the STL.
> 
> Beste Grüße / Best regards,
> Alexander Nassian

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alexander Nassian]

Will there be now 10 BC discussions every year? At least it feels like. Why 
can't it be decided and then accepted by everyone as is? In my personal opinion 
I don't care much about BC but I'm happy that it blocks STL usage because its 
brutally unnatural and I stumbled so often over different behaviors of it on 
different platforms and compilers that I have a real hate on the STL.

Beste Grüße / Best regards,
Alexander Nassian

> Am 19.11.2016 um 10:22 schrieb Иван Комиссаров :
> 
> Maybe we should start another thread about BC?
> I'm not convinced that MacOS is the only system when mixing libc++/stdlib 
> makes sence. On linux you can do the same. If we will use stl, the Qt version 
> installed from packages can't be used for development, you should use 
> libc++/stdlib Qt version from Qt site. Not a problem, really.
> The problem is the incompatibility between compiler versions. I had a plugin 
> build with gcc 4.7 and i spent 2 hours to find the reason why it crashed with 
> library build with gcc 4.8 (i didn't know that compiler updated on build 
> host). The problem was that std::unordered_map was BiC.
> So, Qt have to support each gcc (actually, stdlib/libc++ version) major 
> version.
> And you will have reinstall Qt (almost) each time you update the compiler 
> package.
> Correct me if i'm wrong.
> 
> 2016-11-19 10:04 GMT+03:00 Marc Mutz :
>> On Friday 18 November 2016 22:12:44 Thiago Macieira wrote:
>> > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz 
>> > escreveu:
>> > > 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.
>> >
>> > Which is the reason we can't accept them in our ABI. The rules are
>> > incompatible.
>> 
>> If you extend this argument to its logical conclusion, Qt should be BC 
>> between
>> debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't 
>> Qt?
>> 
>> You see, that argument is completely empty. The STL is forbidden because
>> people are uncomfortable with it, not because it causes BiC. The 
>> debug/release
>> stuff on MSVC is allowed to be BiC because people have come to accept it as
>> reality. Neither one is any more right or wrong inherently, than the other.
>> 
>> Thanks,
>> Marc
>> 
>> --
>> Marc Mutz  | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - The Qt, C++ and OpenGL Experts
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Иван Комиссаров]

Maybe we should start another thread about BC?
I'm not convinced that MacOS is the only system when mixing libc++/stdlib
makes sence. On linux you can do the same. If we will use stl, the Qt
version installed from packages can't be used for development, you should
use libc++/stdlib Qt version from Qt site. Not a problem, really.
The problem is the incompatibility between compiler versions. I had a
plugin build with gcc 4.7 and i spent 2 hours to find the reason why it
crashed with library build with gcc 4.8 (i didn't know that compiler
updated on build host). The problem was that std::unordered_map was BiC.
So, Qt have to support each gcc (actually, stdlib/libc++ version) major
version.
And you will have reinstall Qt (almost) each time you update the compiler
package.
Correct me if i'm wrong.

2016-11-19 10:04 GMT+03:00 Marc Mutz :

> On Friday 18 November 2016 22:12:44 Thiago Macieira wrote:
> > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz
> escreveu:
> > > 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.
> >
> > Which is the reason we can't accept them in our ABI. The rules are
> > incompatible.
>
> If you extend this argument to its logical conclusion, Qt should be BC
> between
> debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't
> Qt?
>
> You see, that argument is completely empty. The STL is forbidden because
> people are uncomfortable with it, not because it causes BiC. The
> debug/release
> stuff on MSVC is allowed to be BiC because people have come to accept it as
> reality. Neither one is any more right or wrong inherently, than the other.
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 18 November 2016 22:12:44 Thiago Macieira wrote:
> Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu:
> > 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.
> 
> Which is the reason we can't accept them in our ABI. The rules are 
> incompatible.

If you extend this argument to its logical conclusion, Qt should be BC between 
debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't Qt?

You see, that argument is completely empty. The STL is forbidden because 
people are uncomfortable with it, not because it causes BiC. The debug/release 
stuff on MSVC is allowed to be BiC because people have come to accept it as 
reality. Neither one is any more right or wrong inherently, than the other.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 19 November 2016 02:17:27 Konstantin Tokarev wrote:
> > If we do nothing else, we should at least use owner whereever
> > possible.
> 
> Wouldn't it be a better idea to use standard language feature to indicate
> ownership, i.e. std::unique_ptr, wherever it makes sense?

Yes, if we could. But BC (see above) and SC will make this impossible for a 
long time to come.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

17.11.2016, 13:33, "Marc Mutz" :
> On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote:
>>  On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
>>  >> Like you maybe have learned there are C++ Core Guidelines. They are
>>  >> already very comprehensive. What about basing the Qt Creator Code
>>  >> Style on it?
>>  >>
>>  >> I see advantages like new developer can easier grasp out rules
>>  >> because they are already familiar with it.
>>  >>
>>  >> We may have to exclude some rules too because they don't fit to us.
>>
>>  Thiago Macieira replied:
>>  > "very comprehensive" is an understatement. Can you point out examples
>>  > of rules you're more interested in? Maybe we should start with a
>>  > whitelist of rules we do want and progressively expand from there.
>>
>>  The guidelines' introduction does, after all, countenance gradual
>>  adoption - especially for existing code-bases - and a general opt-in
>>  approach. Presumably QtC's style is also used for new projects; it may
>>  be worth using a larger subset of the guidelines for new projects as
>>  compared to old; and it probably makes sense to make it easy for users
>>  to configure which of the guidelines they opt in to, for each project.
>
> If we do nothing else, we should at least use owner whereever possible.

Wouldn't it be a better idea to use standard language feature to indicate 
ownership,
i.e. std::unique_ptr, wherever it makes sense?

> We
> can add it to QtGlobal, since we require now enough C++11 to support it:
>
>   namespace gsl {
>   template  using owner = T;
>   }
>
> There, done. It doesn't even interfere with client code including a more
> comprehensive GSL library, because they will define it the same way, and it's
> just a type alias.
>
> One problem is that in Qt, who is the owner is often not clear. But that
> should not prevent us from using it everywhere else.
>
> Than again, no compiler actually checks for this atm, not even MSVC, afaik, so
> if we get it wrong, there's no-one but reviewers to call the mistake...
>
> The bigger problem is that while owner 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 from being
> added to Qt.
>
> My personal opinion is that we're way, WAY, past the tipping point where this
> policy started to hurt Qt more than the convenience of interchanging libc++
> and libstdc++ on OS X gives to the 5 people in the world that use this
> feature. And I'm not at all happy that QtCS chickened out on a decision this
> year. I don't think we can afford to wait for next year's QtCS to maybe-maybe-
> not get rid of that nonsensical rule.
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sexta-feira, 18 de novembro de 2016, às 23:24:15 PST, Marco Bubke escreveu:
> Actually it looks like you cannot agree on your assumptions, so it's maybe
> time to find arguments to provide some agreeable fundamentals. Otherwise I
> don't see how this discussion can be reach any cooperative level at all.

Marco, I asked you to list the rules you specifically want to see adopted at 
first. You haven't replied with that yet.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

On November 18, 2016 22:13:03 Thiago Macieira  wrote:

> Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu:
>> 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.
>
> Which is the reason we can't accept them in our ABI. The rules are 
> incompatible.

Actually GSL owner is simply definded as as alias to *T,  so you can add it 
without breaking any ABI or  API.

And I want to remind you it is about QtCreator, which has no guarantees. So it 
would be nice if you get in context. 

Actually it looks like you cannot agree on your assumptions, so it's maybe time 
to find arguments to provide some agreeable fundamentals. Otherwise I don't see 
how this discussion can be reach any cooperative level at all. 

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu:
> 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.

Which is the reason we can't accept them in our ABI. The rules are 
incompatible.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Thursday 17 November 2016 11:41:25 Marco Bubke wrote:
> I want to remind you this is about Qt Creator, not Qt. Please use a
> different thread for it. [?]

I guess QtC also has some API/BC rules for its plugins?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [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"  wrote:
> >On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote:
> >   > The bigger problem is that while owner 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 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  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Lars Knoll]

On 17/11/16 23:03, "Development on behalf of Thiago Macieira" 
 wrote:

>On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote:
>   > The bigger problem is that while owner 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 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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

18.11.2016, 01:03, "Thiago Macieira" :
> On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote:
>>  The bigger problem is that while owner 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 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).
>
> 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.

"GSL" was standing for GNU Scientific Library for a long time.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote:
> The bigger problem is that while owner 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 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).

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

I want to remind you this is about Qt Creator, not Qt. Please use a different 
thread for it. [?]


From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on 
behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Thursday, November 17, 2016 11:35:54 AM
To: development@qt-project.org
Subject: Re: [Development] Basing Qt Creator Coding Style on C++ Core 
Guidelines?

On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote:
> On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
> >> Like you maybe have learned there are C++ Core Guidelines. They are
> >> already very comprehensive. What about basing the Qt Creator Code
> >> Style on it?
> >>
> >> I see advantages like new developer can easier grasp out rules
> >> because they are already familiar with it.
> >>
> >> We may have to exclude some rules too because they don't fit to us.
>
> Thiago Macieira replied:
> > "very comprehensive" is an understatement. Can you point out examples
> > of rules you're more interested in? Maybe we should start with a
> > whitelist of rules we do want and progressively expand from there.
>
> The guidelines' introduction does, after all, countenance gradual
> adoption - especially for existing code-bases - and a general opt-in
> approach.  Presumably QtC's style is also used for new projects; it may
> be worth using a larger subset of the guidelines for new projects as
> compared to old; and it probably makes sense to make it easy for users
> to configure which of the guidelines they opt in to, for each project.

If we do nothing else, we should at least use owner whereever possible. We
can add it to QtGlobal, since we require now enough C++11 to support it:

  namespace gsl {
  template  using owner = T;
  }

There, done. It doesn't even interfere with client code including a more
comprehensive GSL library, because they will define it the same way, and it's
just a type alias.


One problem is that in Qt, who is the owner is often not clear. But that
should not prevent us from using it everywhere else.

Than again, no compiler actually checks for this atm, not even MSVC, afaik, so
if we get it wrong, there's no-one but reviewers to call the mistake...


The bigger problem is that while owner 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 from being
added to Qt.

My personal opinion is that we're way, WAY, past the tipping point where this
policy started to hurt Qt more than the convenience of interchanging libc++
and libstdc++ on OS X gives to the 5 people in the world that use this
feature. And I'm not at all happy that QtCS chickened out on a decision this
year. I don't think we can afford to wait for next year's QtCS to maybe-maybe-
not get rid of that nonsensical rule.

Thanks,
Marc

--
Marc Mutz <marc.m...@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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote:
> On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
> >> Like you maybe have learned there are C++ Core Guidelines. They are
> >> already very comprehensive. What about basing the Qt Creator Code
> >> Style on it?
> >> 
> >> I see advantages like new developer can easier grasp out rules
> >> because they are already familiar with it.
> >> 
> >> We may have to exclude some rules too because they don't fit to us.
> 
> Thiago Macieira replied:
> > "very comprehensive" is an understatement. Can you point out examples
> > of rules you're more interested in? Maybe we should start with a
> > whitelist of rules we do want and progressively expand from there.
> 
> The guidelines' introduction does, after all, countenance gradual
> adoption - especially for existing code-bases - and a general opt-in
> approach.  Presumably QtC's style is also used for new projects; it may
> be worth using a larger subset of the guidelines for new projects as
> compared to old; and it probably makes sense to make it easy for users
> to configure which of the guidelines they opt in to, for each project.

If we do nothing else, we should at least use owner whereever possible. We 
can add it to QtGlobal, since we require now enough C++11 to support it:

  namespace gsl {
  template  using owner = T;
  }

There, done. It doesn't even interfere with client code including a more 
comprehensive GSL library, because they will define it the same way, and it's 
just a type alias.


One problem is that in Qt, who is the owner is often not clear. But that 
should not prevent us from using it everywhere else.

Than again, no compiler actually checks for this atm, not even MSVC, afaik, so 
if we get it wrong, there's no-one but reviewers to call the mistake...


The bigger problem is that while owner 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 from being 
added to Qt.

My personal opinion is that we're way, WAY, past the tipping point where this 
policy started to hurt Qt more than the convenience of interchanging libc++ 
and libstdc++ on OS X gives to the 5 people in the world that use this 
feature. And I'm not at all happy that QtCS chickened out on a decision this 
year. I don't think we can afford to wait for next year's QtCS to maybe-maybe-
not get rid of that nonsensical rule.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Edward Welbourne]

On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
>> Like you maybe have learned there are C++ Core Guidelines. They are
>> already very comprehensive. What about basing the Qt Creator Code
>> Style on it?
>>
>> I see advantages like new developer can easier grasp out rules
>> because they are already familiar with it.
>>
>> We may have to exclude some rules too because they don't fit to us.

Thiago Macieira replied:
> "very comprehensive" is an understatement. Can you point out examples
> of rules you're more interested in? Maybe we should start with a
> whitelist of rules we do want and progressively expand from there.

The guidelines' introduction does, after all, countenance gradual
adoption - especially for existing code-bases - and a general opt-in
approach.  Presumably QtC's style is also used for new projects; it may
be worth using a larger subset of the guidelines for new projects as
compared to old; and it probably makes sense to make it easy for users
to configure which of the guidelines they opt in to, for each project.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
> Like you maybe have learned there are C++ Core Guidelines. They are already
> very comprehensive. What about basing the Qt Creator Code Style on it?
> 
> 
> I see advantages like new developer can easier grasp out rules because they
> are already familiar with it.
> 
> We may have to exclude some rules too because they don't fit to us.

"very comprehensive" is an understatement. Can you point out examples of rules 
you're more interested in? Maybe we should start with a whitelist of rules we 
do want and progressively expand from there.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development