On Wednesday, 3 May 2023 11:14:55 PDT Marc Mutz via Development wrote:
> [Sorry, yes, 6.9 is in spring '25. I messed up the counting]
As a native of the Southern Hemisphere, I ask that we use dates, not seasons
to refer to times. Everyone knows that Spring happens in September, right
before we
On Wednesday, 3 May 2023 11:15:19 PDT Marc Mutz via Development wrote:
> That might be so, and I'm not Maurice or Vladimir, but if I was to
> decide, I wouldn't commit my company to a roadmap that requires forward
> binary compatibility from stdlib vendors without a written declaration
> from each
On Wednesday, 3 May 2023 10:40:18 PDT Marc Mutz via Development wrote:
> So if it's a vote: +1 for all new enums being scoped and +1 for all old
> enums being made scoped come Qt 7.
With the same trick that C++20 did for std::memory_order?
enum class memory_order : int
{
relaxed,
On Wednesday, 3 May 2023 10:51:18 PDT Jaroslaw Kobus via Development wrote:
> "enum class" has one advantage over "enum" inside a "class" : you may
> forward declare the "enum class", while the other not. That's quite often
> case that your header must include the other header just because you use
[re-ordered]
On Wed, May 03, 2023 at 05:32:46PM +, Axel Spoerl via Development
wrote:
> > On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development
> > wrote:
> >
> > 02/05/23 10:58, Volker Hilsheimer via Development ha
> > scritto:
> >> During the header review, but also in API
On 03.05.23 18:03, Thiago Macieira wrote:
> On Tuesday, 2 May 2023 23:16:19 PDT Marc Mutz via Development wrote:
>> [1] I also heard the idea to make C++20 mandatory for building Qt, but
>> user projects could continue to use C++17. That would require _forward_
>> binary compatibility between
On 03.05.23 18:24, Thiago Macieira wrote:
> On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote:
>> While I'd rather sooner than later see us switch to C++20, ever since
>> 5.7, we have dropped supported compilers only after an LTS release (5.6,
>> in that case).
>
> We are after
"enum class" has one advantage over "enum" inside a "class" : you may forward
declare the "enum class", while the other not. That's quite often case that
your header must include the other header just because you use the "enum" in
"class" in your API and nothing more.
Jarek
On Wed, May 03, 2023 at 03:21:40PM +0200, Giuseppe D'Angelo via Development
wrote:
> Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
> >
> > What started as an attempt to provide a few building blocks for making it
> > easier to build asynchronous APIs taking any kind of
On 03.05.23 19:22, Thiago Macieira wrote:
> On Wednesday, 3 May 2023 09:40:42 PDT Giuseppe D'Angelo via Development wrote:
>> To me it's a no brainer: any new enumeration
>> added to Qt shall be an enum class.
>
> I'd say that any new enumeration in the Qt namespace should be enum class, but
>
On 3 May 2023, at 19:22, Thiago Macieira wrote:
I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're sufficiently descriptive already.
Agreed, and this is also what our current API design guide says:
On 3 May 2023, at 18:40, Giuseppe D'Angelo via Development
wrote:
Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
During the header review, but also in API discussions leading up to it, we had
a few cases where it would have helped if we had clearer guidelines about when
to
+1 for every new enum added being an enum class. Exceptions to be approved here
case by case.
> On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development
> wrote:
>
> Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
>> During the header review, but also in API discussions
On Wednesday, 3 May 2023 09:40:42 PDT Giuseppe D'Angelo via Development wrote:
> To me it's a no brainer: any new enumeration
> added to Qt shall be an enum class.
I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're
On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote:
> The standing proposal is to move to C++20 with Qt 6.9, after the next LTS
> release. I see no pressing reasons to accelerate that. The value of the
> features Thiago listed - which excludes all the big stuff anyway -
Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
During the header review, but also in API discussions leading up to it, we had
a few cases where it would have helped if we had clearer guidelines about when
to use scoped enums, and when not.
Scoped enums have some clear
On Wednesday, 3 May 2023 09:23:53 PDT Philippe wrote:
> Not yet available with Apple CLang (I did not test today, but a fews ago).
$ clang -E -include bit -xc++ -std=c++20 /dev/null > /dev/null
$ clang --version; date
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target:
On Tuesday, 2 May 2023 23:01:57 PDT Maurice Kalinowski via Development wrote:
> We even have customers who are not able to upgrade to C++17 yet due to
> supply chain issues.
Hello Maurice
Can you provide more details on what the difficulties are and when relief
should
be expected for this?
On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote:
> While I'd rather sooner than later see us switch to C++20, ever since
> 5.7, we have dropped supported compilers only after an LTS release (5.6,
> in that case).
We are after an LTS release (6.5). We could have done this for
>> header
Not yet available with Apple CLang (I did not test today, but a fews ago).
Philippe
On Tue, 02 May 2023 17:39:01 -0700
Thiago Macieira wrote:
> C++23 is on the way, so maybe it's time for us to raise our minimum to the
> one
> version before that. Let's aim for Qt 6.7, because
On Wednesday, 3 May 2023 05:59:26 PDT Vladimir Minenko via Development wrote:
> “…1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
> 2. C++20 is required for the development of Qt itself -
> https://bugreports.qt.io/browse/QTBUG-109361
Which stage are we in? I think we're
On Tuesday, 2 May 2023 23:16:19 PDT Marc Mutz via Development wrote:
> [1] I also heard the idea to make C++20 mandatory for building Qt, but
> user projects could continue to use C++17. That would require _forward_
> binary compatibility between stdlib implementations. Given that a C++20
> stdlib
Bumping this thread up in your inboxes as it includes the links to the JIRA
tickets where the journey towards C++20 has been planned and discussed so far.
Let's try to build on what we already know.
The standing proposal is to move to C++20 with Qt 6.9, after the next LTS
release. I see no
On 3 May 2023, at 15:21, Giuseppe D'Angelo via Development
wrote:
Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
What started as an attempt to provide a few building blocks for making it
easier to build asynchronous APIs taking any kind of callable (like
QTimer::singleShot
Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
What started as an attempt to provide a few building blocks for making it
easier to build asynchronous APIs taking any kind of callable (like
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a
longer
Hello all,
on this occasion, I would like to call the Qt Development community for
conscious and pragmatic decisions when it comes to changes in the "minimum C++
standard”.
For some reason, Qt became known to do these switches on some “surprising"
basis. I recall well as a colleague was
Hi all,
> What started as an attempt to provide a few building blocks for
making > it easier to build asynchronous APIs taking any kind of
callable (like > QTimer::singleShot ...
Sorry for posting without checking your implemented solution:
one of the goals of my QSkinny (
On 2023-05-03, Thiago Macieira wrote:
> 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian
> will
> probably release its next stable before Qt 6.7, though whether it'll still
> upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum
Debian 12
Perhaps we should start by using C++20 by default if supported, and then later
require it? It seems we are missing a step.
Best regards
Allan
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi Maurice,
On 03.05.23 08:01, Maurice Kalinowski wrote:
> Basically, the idea from our end has been to take a two-step approach by
> first enabling every developer to use C++20 in their projects and potentially
> add helpers/functionality where possible. Only at a later stage we can then
>
As Marc already mentioned, we are having troubles with users not being able to
upgrade on various platforms.
We even have customers who are not able to upgrade to C++17 yet due to supply
chain issues.
Basically, the idea from our end has been to take a two-step approach by first
enabling
31 matches
Mail list logo
