Hi Thiago,
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).
Since I agree the train for 6.6 has left the station, as Integrity (and
possibly QNX?) don't have an official C++20
Qt 6.5 status
* Branching from '6.5' to '6.5.1' done
* Qt 6.5.1 release preparations ongoing
* Target is to release Qt 6.5.1 Wed 10th May
Qt 6.6 status
* Only a month left to implement new features for Qt 6.6
* the whatsnew66.qdoc document here:
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 feature-freeze for 6.6 is
within one month, and lets us warn our users this is coming.
By this, I mean to:
* modify our build system so Qt compiles with -std=c++20
Hi,
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 journey to the core.
[1]
I think 'yes' is an easy answer. Having a convention that matches the
is_same/is_same_v enable_if/enable_if_t paradigm could make some things
easier, avoiding the need to wrap constexpr bool values in bool_constant
when there is no non-'_v' version of the check yet.
But someone also has to write
Hi,
We’ll have our scheduled maintenance break on next Monday (8th of May). We’ll
begin our work at 5:00 UTC and you can prepare for 6 hours of CI not working.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Volker Hilsheimer (2 May 2023 10:57) wrote:
> With Qt 6.5 out for a while already, and roughly a month to go until
> Qt 6.6 feature freeze and the start of the various activities that
> lead up to the release, it’s perhaps not too early to review some of
> the pain points we experienced with 6.5,
Hi,
while gerrit _didn't_ have support for it, that changed in 3.7. It needs
to be manually enabled
(https://www.gerritcodereview.com/3.7.html#mention-user-support), but
maybe that would be a good way forward?
Fabian
On 02.05.23 11:00, Volker Hilsheimer via Development wrote:
With Qt 6.5,
With Qt 6.5, it’s been a struggle to get people to respond and follow-up to
comments made during the header review process.
Gerrit doesn’t really care about @user-style mentioning in comments, even
though is seems that some people assume that it does. Creating JIRA tickets is
the official way
During header review we identified a few cases where e.g. using
std::conjunction/disjunction wasn’t used, or not used optimally. Using
suboptimal constructs can result in significant compile-time penalties.
We generally don’t have a lot of guidelines for template-meta-programming.
Should we
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 technical advantages (such as better type safety,
thanks to no implicit
Hi,
With Qt 6.5 out for a while already, and roughly a month to go until Qt 6.6
feature freeze and the start of the various activities that lead up to the
release, it’s perhaps not too early to review some of the pain points we
experienced with 6.5, and discuss how we can improve.
In
12 matches
Mail list logo
