Re: [Development] Raising the minimum to C++20
On Tuesday, 9 May 2023 23:01:11 PDT Marc Mutz via Development wrote: > "The GCC dev_s_", or "one GCC dev"? And who? Jonathan? [citation needed] Jonathan and Thomas Rogers, but it was the consensus opinion when I brought up some decisions in that are ABI and should have been given some more thought before being enabled. The discussion happened on the ML back in 2021 and in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277 Please specifically see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277#c23 "(Un)fortunately, the entire implementation detail in the headers will change, most likely with GCC14 (ideally moving most of the implementation into the .so). As Jonathan points out, this hardly the only experimental feature area within libstdc++ that has undergone such changes." > Pardon my French, but that sounds like ass-covering :) It seems they're serious about it. BTW, I think we don't need to require that C++20-defaulting compiler as our minimum. We just need it to exist, so we can analyse whether it generates ABI- compatible code for everything that is used in our ABI and in pre-C++20 inline code. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] is property compliance of vah264dec an int or a string?
sorry eddy. Wrong forum. Joe On Wednesday, May 10, 2023, 03:59:53 a.m. EDT, Edward Welbourne wrote: Joe (cfd new, 9 May 2023 17:59) wrote: > I made a pipeline to receive rtsp streaming with vah264dec > compliance=flexible. Given that the token "vah264dec" does not appear in any Qt source code I have checked out, I suspect you need to give more context to what you're asking about and at least some hint to how it relates to Qt. Did you, in fact, mean to send this to a mailing-list related to gstreamer ? Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] is property compliance of vah264dec an int or a string?
Joe (cfd new, 9 May 2023 17:59) wrote: > I made a pipeline to receive rtsp streaming with vah264dec > compliance=flexible. Given that the token "vah264dec" does not appear in any Qt source code I have checked out, I suspect you need to give more context to what you're asking about and at least some hint to how it relates to Qt. Did you, in fact, mean to send this to a mailing-list related to gstreamer ? Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] (To what extent) Should we start the API change review earlier ?
Volker Hilsheimer (9 May 2023 17:01) wrote: > The primary purpose of the header review is to catch *technical* > mistakes - BC or SC breakages - rather than to discuss API design, > naming, or style. Some technical errors are future-readiness: as long as we have BC and SC commitments, we have to think about whether what we design today will leave us with a BC or SC constraint preventing us from improving on today's design later, when new requirements surface or we discover any limitations of the initial design. Consequently, discussions of API design, naming and even style can be relevant to determining whether we have made a technical error in the present design. > So starting the header review process when we still expect changes > might not be useful. I think starting it when we are in beta makes > sense. We certainly can't close a review until after FF, even if we do start one before. The advantage of starting early is to give more time for the conversations to happen and the consequent fixes to be sorted out. > But the reality is that the header review got rather conflated with > API review (and, as far as template code in headers is concerned, even > implementation review) in the last iterations. And while that is > sometimes ok, the header review isn’t the right process to discuss the > design of more complex frameworks. Obviously the best time to review a new API or a change to API is when it is first introduced, long before FF or the API change review. All the same, the latter can bring more eyes to the change and more insights into potential problems with the change. The initial change was typically reviewed by folk working closely with the particular part of the code-base; the API change review is apt to bring the change to the attention of potential clients of the new API, or to folk who've previously designed similar-shaped APIs for other purposes, who may have valuable insights into the new design. OTOH, when we're all rushing headlong towards the deadline of FF, an early start to the API change review might be of limited value, simply because relevant folk are too busy to have those conversations. And the part of the process which has been slow at recent releases has been getting all the modules signed off by their respective Maintainers; it's not really clear to me that an earlier start would help with that. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
> On 10 May 2023, at 07:39, Marc Mutz via Development > wrote: >> >> >> That said. I find discussing style-guides in general a waste of time, and >> will >> agree to anything that make us stop wasting time on this. > > I tend to agree, but the choice is either to define it centrally, or you > repeat these discussions on Gerrit over and over again. Thanks for the proposals Marc, the list looks good to me. As for >>> - space after template and before <: >>> >>>// WRONG >>>template >>>// CORRECT: >>>template I was wondering what cppreference suggests, and was delighted to find that the first few lines of https://en.cppreference.com/w/cpp/memory/unique_ptr manage to have both :) So accepting either, and in particular the no-space form that comes out of _clang-format, is fine. Encoding this in the sanity bot and/or in _clang-format avoids that we waste time on this during code review. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Mittwoch, 10. Mai 2023 08:01:11 CEST Marc Mutz via Development wrote: > On 10.05.23 01:21, Thiago Macieira wrote: > > On Tuesday, 2 May 2023 17:39:01 PDT Thiago Macieira wrote: > >> Opinions? > > > > BTW, here's the opinion of the GCC devs: > > > > Don't ever use the -std= option to raise the language from the default. > > That implies opting in to functionality that they're not entirely > > satisfied with, and may possibly still break ABI. > > "The GCC dev_s_", or "one GCC dev"? And who? Jonathan? [citation needed] > > BTW: Did any GCC version ever default to C++11? IIRC, they went from > 98/03 straight to 14 (which I agree with, but that's another story). > Yeah. The discussion was on what was the expected default. When they suggested switching to C++11, I proposed just going with C++14 directly being a "bug- fix" of C++11, and that side won out. In any case the gcc default is not just what they satisfied with. It is based on lazily updating stable defaults, and discussions on the mailing list. Though the documentation still marks C++20 support as "experimental". So I guess they could justify breaking it if they wanted to. Especially the coroutines and modules which are not enabled by default with std=c++20. I find it highly unlikely they would break what works by default with std=c++20 though, even in ABI. It is not the sort of thing that goes over well. 'Allan -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On 10.05.23 01:21, Thiago Macieira wrote: > On Tuesday, 2 May 2023 17:39:01 PDT Thiago Macieira wrote: >> Opinions? > > BTW, here's the opinion of the GCC devs: > > Don't ever use the -std= option to raise the language from the default. That > implies opting in to functionality that they're not entirely satisfied with, > and may possibly still break ABI. "The GCC dev_s_", or "one GCC dev"? And who? Jonathan? [citation needed] BTW: Did any GCC version ever default to C++11? IIRC, they went from 98/03 straight to 14 (which I agree with, but that's another story). Pardon my French, but that sounds like ass-covering :) Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
