On Mon, 9 Jun 2025 at 12:44, Petri Virkkunen via Development
wrote:
>
> Hi, I’d like to ask for a late exception for two changes extending our Qt
> Quick for Android API.
>
>
>
> First change: https://codereview.qt-project.org/c/qt/qtdeclarative/+/644210,
> reason for the delay is partially due
On Tue, 27 May 2025 at 18:37, Volker Hilsheimer via Development
wrote:
> Two thoughts:
>
> - how does TaskTree fit into a C++26 future with sender/receiver
A quick look based on documentation:
1) it's easy to fit a TaskTree into a sender pipeline, it has signals,
so the generic adaptation will j
On Wed, 14 May 2025 at 18:53, Elvis Stansvik wrote:
>
> Den ons 14 maj 2025 12:32Volker Hilsheimer via Development
> skrev:
>>
>> > On 12 May 2025, at 13:29, Kevin Kofler via Development
>> > wrote:
>> >
>> > Volker Hilsheimer via Development wrote:
>> >> I suspect that “Adaptor” will be a goo
On Tue, 14 Jan 2025 at 11:13, Ivan Solovev via Development
wrote:
> I tried to start a similar discussion in October [0], but there was no real
> conclusion apart from "let's decide on a case-by-case basis".
>
> My idea was that we can at least use the new to-be-removed approach on the
> APIs that
On Fri, 27 Dec 2024 at 19:26, Axel Spoerl via Development
wrote:
>
> Hi everyone,
>
> hopefully you have all had a merry Christmas and the year 2024 is gracefully
> moving towards new year's eve.
> I would like to draw your attention to
> https://codereview.qt-project.org/c/meta/quips/+/597911
>
On Wed, 23 Oct 2024 at 11:33, Jøger Hansegård via Development
wrote:
>
> Thank you, Lars, for designing, developing, and maintaining Qt Multimedia,
> which made it a great module for Artem to take over.
>
> +1 for Artem
Agreed on all counts, and +1 for Artem.
--
Development mailing list
Develop
On Thu, 19 Sept 2024 at 17:35, Volker Hilsheimer via Development
wrote:
> My preference would be "static constexpr inline”, as static is the most
> important piece of information (storage and calling convention in case of
> member functions), constexpr is “good to know”, and inline is in practic
On Sun, 8 Sept 2024 at 16:27, Nicolas Fella via Development
wrote:
>
> Hi,
>
> at Akademy I had a chat with Volker Hilsheimer and now want to open this
> to a wider audience.
>
> In KDE we have an automatic crash reporting system based on Sentry.
> Naturally some amount of the crash reports point
On Thu, 5 Sept 2024 at 12:24, Thiago Macieira wrote:
>
> On Thursday 5 September 2024 10:41:51 CEST Ville Voutilainen wrote:
> > Well, not necessarily. Consider QVector::operator[]. You can make that
> > non-noexcept, slap a precondition
> > on it, and use a th
On Wed, 4 Sept 2024 at 14:35, Thiago Macieira wrote:
> > I also question the notion of "we don't do exceptions in Qt" popping up
> > between the lines in this thread. We _do_ support them in QtCore and
> > QtTest, and it's Core you're proposing to plaster with noexcept.
>
> We partially support th
On Tue, 3 Sept 2024 at 18:36, Marc Mutz via Development
wrote:
>
> On 31.08.24 20:01, Ville Voutilainen wrote:
> > On Fri, 30 Aug 2024 at 19:21, Thiago Macieira
> > wrote:
> >> For the non-simple cases, we may need two macros, one that expands to:
> >>
> &
On Fri, 30 Aug 2024 at 19:21, Thiago Macieira wrote:
> For the non-simple cases, we may need two macros, one that expands to:
>
> noexcept(noexcept(std::string_view{"", 1}))
>
> and the other that expands to the pre() specifier.
Right. Maybe
void f(int x) Q_NARROW_CONTRACT_NOEXCEPT Q_PRE(x >=
On Fri, 30 Aug 2024 at 06:17, Ville Voutilainen
wrote:
>
> On Fri, 30 Aug 2024 at 04:59, Thiago Macieira
> wrote:
>
> > Said macro should be tied to the precondition itself, if we can. I haven't
> > looked at the syntax: can one macro in one location expand to prec
On Fri, 30 Aug 2024 at 04:59, Thiago Macieira wrote:
> Said macro should be tied to the precondition itself, if we can. I haven't
> looked at the syntax: can one macro in one location expand to preconditions-
> or-noexcept-or-both?
Yes. Here's an example of the syntax for you:
void f(int x) noe
On Thu, 29 Aug 2024 at 18:34, Thiago Macieira wrote:
>
> On Thursday 29 August 2024 06:43:58 GMT-7 Marc Mutz via Development wrote:
> > I'm ok with 1-3, I'm not ok with 4.
> >
> > The state of the art is what the std prescribes, not what a stdlib
> > implementation does. stdlibs are magic; they ca
On Wed, 28 Aug 2024 at 13:26, Volker Hilsheimer via Development
wrote:
> Since Lakos is referenced in this thread, two quotes from the paper [1] that
> resulted in P3155R0 [2], aka “The Lakos Rule”:
>
> On page 5 of [1]:
>
> > What Are We Proposing
> > In order to support effective testing, compi
On Tue, 27 Aug 2024 at 22:23, Thiago Macieira wrote:
>
> On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote:
> > On Tue, 27 Aug 2024 at 17:15, Thiago Macieira
> wrote:
> > > The point is that this putative mistake has no consequences, today. It
> > &
On Tue, 27 Aug 2024 at 17:15, Thiago Macieira wrote:
> The point is that this putative mistake has no consequences, today. It remains
> to be seen whether it will with contracts, when those come. When contracts
> come, if those noexcept are a problem, then both libc++ and libstdc++ will
> deploy a
On Tue, 27 Aug 2024 at 05:21, Thiago Macieira wrote:
>
> On Monday 26 August 2024 17:18:22 GMT-7 Ville Voutilainen wrote:
> > So eventually such libraries
> > need to
> > be fixed so that they ship configurations and builds where such
> > functions can be compiled
On Tue, 27 Aug 2024 at 05:23, Thiago Macieira wrote:
>
> On Monday 26 August 2024 17:09:54 GMT-7 Ville Voutilainen wrote:
> > I would think the callee takes over the responsibility of destroying
> > the parameters when they have all been initialized
> > (so that you actua
On Tue, 27 Aug 2024 at 05:18, Thiago Macieira wrote:
>
> On Monday 26 August 2024 15:35:11 GMT-7 Ville Voutilainen wrote:
> > > a) turning precondition checks into runtime validations
> > > b) using exceptions for the runtime validation
> > > c) violating
On Tue, 27 Aug 2024 at 02:24, Thiago Macieira wrote:
>
> On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> > "Q_ASSERT don't affect noexceptness"
> >
> > Or
> >
> > "noexcept(false) if you call other, noexcept(false) functions from your
> > code", which includes all the pthread canc
On Tue, 27 Aug 2024 at 02:13, Thiago Macieira wrote:
>
> On Monday 26 August 2024 15:25:40 GMT-7 Ville Voutilainen wrote:
> > There's a difference between a function being noexcept and calls to a
> > function not throwing exceptions. Parameter initialization
> > can t
On Tue, 27 Aug 2024 at 02:10, Thiago Macieira wrote:
> > A contract violation turned into an exception cannot escape out of a
> > noexcept function. So it won't bubble up.
>
> I think that's a mistake, but since I don't use exceptions, I also don't care.
It isn't. It avoids functions being condit
On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development
wrote:
> What is unacceptable in (1) (doing nothing) is not even _informing_
> users about what we found¹, so _they_ can decide for themselves what to do.
>
> ¹ neither at compile-time, nor runtime, nor coding time (static checker)
>nor a
On Mon, 26 Aug 2024 at 22:29, Giuseppe D'Angelo via Development
wrote:
>
> Il 26/08/24 19:56, Thiago Macieira ha scritto:
> > I'd like to request Qt code not obey that rule. In my opinion, it's a defect
> > in the contract implementation rather than on Qt code. The*pre* condition
> > indicates so
On Mon, 26 Aug 2024 at 22:51, Thiago Macieira wrote:
>
> On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> >
> > > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > > defect
> in the cont
On Mon, 26 Aug 2024 at 23:25, Fabian Kosmale via Development
wrote:
>
> Hi,
>
> I'm somewhat sympathetic to Thiago's proposal, but with different reasoning.
> The Lakos rule is indeed motivated by contracts, and by the fact that the
> standard is extremely reluctant to do breaking changes.
> Now
On Sat, 9 Dec 2023 at 18:16, Thiago Macieira wrote:
>
> On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote:
> > After spending countless hours between Ivan and myself fighting GCC's
> > mysteriously-vanishing support for __int128_t (= qint128),
> > it turns out that with -ans
On Mon, 26 Aug 2024 at 08:26, Marc Mutz via Development
wrote:
> My vote goes to (3). (2) is a good intermediate step (e.g. for Qt 6,
> with Qt 7 converting to static_assert()). Remember that ctors are
> implicitly noexcept in C++, so you need to do actual work to make a type
> that's not nothrow_
On Wed, 21 Feb 2024 at 14:33, Jani Heikkinen via Development
wrote:
> > What kind of performance issues are we talking about?
>
> It takes quite a time to show all releases when you select 'archive'
> category. With latest online installer this is already much better than
> earlier but it stil
On Wed, 21 Feb 2024 at 21:38, apoenitz wrote:
> >Use unnamed namespaces for all internal/non-exported entities. Functions
> > can
> >alternatively be marked `static` in the global namespace. Marking
> > functions
> >`static` also in the unnamed namespace can help readability,
> > p
On Wed, 21 Feb 2024 at 19:56, Thiago Macieira wrote:
>
> On Wednesday, 21 February 2024 09:19:19 PST Mathias Hasselmann via Development
> wrote:
> > How that?
> >
> > https://wiki.qt.io/Coding_Conventions#Things_to_avoid says:
> >
> > "Avoid the use of anonymous namespaces in favor of the static k
On Sat, 16 Dec 2023 at 13:22, apoenitz wrote:
>
> On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote:
> > On 13.12.23 18:36, Thiago Macieira wrote:
> > > So, +1 for me on going ahead.
> >
> > Thanks!
> >
> > Is anyone else here for/against?
>
> To me this doesn't look like a
On Thu, 7 Dec 2023 at 12:33, Giuseppe D'Angelo
wrote:
> * For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support
> on the radar?
Yes, it's on the radar for QNX 8, which is not released yet.
> Is there an online resource showing their commitment at
> maintaining it? Is there the pos
On Thu, 30 Nov 2023 at 12:52, Giuseppe D'Angelo via Development
wrote:
>
> Hi,
>
> OpenSSL 1 has reached EOL last September:
>
> > https://www.openssl.org/blog/blog/2023/09/11/eol-111/
>
>
> Qt has supported OpenSSL 3 for a while, and so last week I pushed a
> patch to drop OpenSSL 1 support from
On Tue, 29 Aug 2023 at 13:28, Volker Hilsheimer via Development
wrote:
>
> +1 in general.
Likewise, +1 in general.
My additional two cents: I have participated in Qt-using projects that
did communications between vehicles and a back-end
using AMQP, and used AMQP between back-end microservices. A
On Thu, 4 May 2023 at 10:54, Marc Mutz via Development
wrote:
>
> On 04.05.23 00:39, Thiago Macieira wrote:
> > And yet, the list of things we want from C++20 is not that big. It's nowhere
> > as complex as C++11 and I'd argue that even the 17 upgrade for Qt 6.0 was a
> > bigger jump. Unless we ad
On Wed, 3 May 2023 at 03:41, 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 feature-freeze for 6.6 is
> within one month, and lets us warn our users this is coming.
>
> By this, I mean t
On Mon, 10 Oct 2022 at 13:13, Hasselmann Mathias
wrote:
>
> I am surprised by the question: "It's non-standard and it's behavior is
> undefined" actually should be enough to avoid such feature.
>
> Actually if a reliable implementation of "#pragma once" would be
> possible, that feature would have
On Tue, 15 Jun 2021 at 12:24, Christian Kandeler
wrote:
>
> +1
+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Mon, 10 May 2021 at 10:10, Samuli Piippo wrote:
>
> Hi all,
>
> I'd like to nominate Mikko Gronoff as approver for the Qt Project.
> Mikko has been tirelessly working together with the release team to
> make sure the embedded releases are always better than the last one.
> Although he is not ac
On Sat, 22 May 2021 at 04:09, Giuseppe D'Angelo via Development
wrote:
>
> Hi,
>
> As detailed in the other thread, I'd like to gather lazy consensus for
> moving the official IRC presence from Freenode to Libera.Chat.
>
> Please use this thread for voting ONLY. Apologies for all the formality,
>
On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development
wrote:
>
> Il 05/03/21 12:08, Tor Arne Vestbø ha scritto:
> > This seems like a bug though? From an API point of view, I’d expect this
> > simple assignment to JustWorkTM, without requiring syntactic sugar all
> > over the place. Shoul
On Thu, 4 Mar 2021 at 02:03, Jason H wrote:
> > The language parts are there in C++20; what's missing from the standard
> > library are "ready-made" coroutines types (task, generator, ...),
> > awaitable types, utility functions for scheduling execution, etc.
> >
> > I've been wondering for a lit
On Mon, 1 Mar 2021 at 15:31, Lars Knoll wrote:
> To fix this, we have now added a new feature (called parallel staging
> branches), where CI rounds are not serialised anymore. Instead, COIN will
> start a new CI run 15 minutes after a change (or a set of changes) got
> staged. It will start tha
On Wed, 24 Feb 2021 at 12:26, Joerg Bornemann wrote:
>
> On 2/24/21 9:30 AM, Bogdan Vatra wrote:
>
> > Do you still believe that I'm one of the few affected by this?
> > Don't you think that everyone who's using cross compiling is affected?
>
> I have seen cross-compiling folks using the cross-pla
On Tue, 16 Feb 2021 at 17:08, André Pönitz wrote:
> I agree that update-alternatives is Just Wrong for something that
> should effectively be the user's decision (and not even a decision
> for all of the user's projects but something that needs to be done
> case-by-case).
>
> On the other hand I d
On Tue, 16 Feb 2021 at 15:35, Kai Köhne wrote:
> And again, this is not something limited to Qt. Last time I checked, the
> executable to run Python 3 on Windows is python.exe, not python3.exe. On
> Debian at least it's python3. This hasn't blocked Python from being perceived
> as overall begin
On Wed, 6 Jan 2021 at 09:14, Richard Weickelt wrote:
>
> > Right. That will become an issue in 4 months when GCC 11 ships with its
> > internal
> > header-dependency refactorings, breaking all sorts of Qt code, and
> > that will then
> > bubble down to various distro downstreams during this year
On Tue, 5 Jan 2021 at 22:22, Max Paperno wrote:
> I'm so sick of "scheduled releases come hell or high water" in the
> programming world (in general, not just Qt). The quality is (usually)
> crap. Once upon a time this release quality was called
> Alpha/Beta/Preview/NFP (not for production). Qt
On Tue, 5 Jan 2021 at 21:42, Thiago Macieira wrote:
> > 2) support for newer compilers/OS versions/etc. that may cause trouble.
> Currently a non-issue, since Qt 5.15 is less than a year old. It may become an
> issue in two or three years' time, but hopefully by then the Qt 6.x content
> set will
On Thu, 12 Nov 2020 at 17:11, Lars Knoll wrote:
> Language Lawyer Hat: is_trivial is the wrong type trait when it comes to
> detect trivial copiability anyhow, example:
>
> struct S { int i; S operator=(const S &)=delete; };
>
> is trivial and not copy assignable. Isn't C++ a fun language to wo
On Tue, 22 Sep 2020 at 17:20, Thiago Macieira wrote:
> And especially if there's no impact to how the user uses the API.
>
> > 1)
> > std::optional compare();
> >
> > 2)
> > enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
> > };
> > Ordering compare();
> >
> > 3)
> > Imp
On Sun, 20 Sep 2020 at 09:02, Thiago Macieira wrote:
> Hmm... I had clearly forgotten about QNX and INTEGRITY, especially the latter.
> I thought the problem with QNX was solved since they switched to Clang (or
> haven't they?).
QNX 7 AFAIK has a compiler based on GCC 8. Switching to Clang doesn
On Sun, 20 Sep 2020 at 09:06, Thiago Macieira wrote:
> > You can't write a conversion from a type you don't own to an int, or
> > vice versa. Don't fall into that trap, it's impossible
> > to dig yourself out of it.
>
> Sorry, I don't understand the issue.
>
> I'm thinking of an internal function
On Sat, 19 Sep 2020 at 06:28, Thiago Macieira wrote:
> But for other things, I'm not shy about it. People can't complain that they
> can't use features that didn't exist when they wrote their application. If
> they want to use new features, it stands to reason they've just upgraded Qt.
> If they
On Fri, 18 Sep 2020 at 21:58, Thiago Macieira wrote:
> Anyway, the int suffices because we only need four values: equal/equivalent,
> less than, greater than, unordered. We can even adopt the same values:
> // less=0xff, equiv=0x00, greater=0x01, unordered=0x02
> or we can use -127 for unorder
On Fri, 18 Sep 2020 at 18:13, Thiago Macieira wrote:
>
> On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> > std::optional QVariant::compare(const QVariant &other);
> >
> > Would that be good enough?
>
> Why the optional?
>
> We should use one of the types from [1]. Yes, it's C++20; we
On Thu, 10 Sep 2020 at 16:04, Andrei Golubev wrote:
>
> Should I expect to do a reserve call with a *smaller* value than my
> current size is before removing elements from
> a container, in order to set a "target size"? For any standard
> container, such a reserve is a complete noop because
> it c
On Thu, 10 Sep 2020 at 11:46, Andrei Golubev wrote:
>
> That's interesting. So the container remembers what sort of a reserve
> request I made on it, and uses
> that as the preferred size whenever the element count of the container
> changes?
>
> Yes. Calling reserve typically means that you do n
On Wed, 9 Sep 2020 at 16:38, Andrei Golubev wrote:
>
> I don't understand what this means. Am I supposed to reserve a
> container to its current size before erasing elements
> from it, if I don't want the erase to shrink it?
>
> Yes.
That's interesting. So the container remembers what sort of a r
On Wed, 9 Sep 2020 at 11:58, Andrei Golubev wrote:
> On the other hand, "please do not free memory, I still need it" use-case is
> also justified. However, chances are that when you really need a certain
> memory to be allocated/preserved, there is a call to QList::reserve() prior
> to insertio
On Wed, 2 Sep 2020 at 17:16, Andrei Golubev wrote:
>
> With this setup, one might be tempted to optimize erasure in the first
> half of the container by shifting elements towards the end (rather than
> from the end towards the beginning), as it would be cheaper. I guess
> that's what's happening h
On Wed, 2 Sep 2020 at 15:19, Andrei Golubev wrote:
> Ville:
>
> Interesting. I'm curious what sort of repacking happens on erase
>
> The iterators before or after may be invalidated. Exactly which of the two
> (before or after) is going to happen depends on the position of the
> to-be-erased ran
On Tue, 1 Sep 2020 at 20:44, Giuseppe D'Angelo via Development
wrote:
>
> Il 01/09/20 19:33, Thiago Macieira ha scritto:
> > All non-const functions that may detach should be coded so they DO detach.
> > That is, after any and all non-const functions, the refcount of the
> > container
> > should
On Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
> > QtGui:
> > * QTextCursor
> > * QTextDocument (find offset, character{At,Count})
> > * QTextLayout
> > * QValidator and subclasses (validate offset)
>
> These here are questionable. Editing a text file with more than 2G
> characters? Sounds unlik
On Mon, 24 Aug 2020 at 15:37, Christian Kandeler
wrote:
> > I don't have verifiable evidence examples, but the gist of it is this:
> >
> > ConcreteType x = foo(); // this detects API breaks right here, right now
> > ...
> > ...
> > ...
> > some_use_of(x);
> >
> > With AAA, this might become
> >
>
On Mon, 24 Aug 2020 at 12:17, Mathias Hasselmann
wrote:
> >> C++ also has a solution for that problem:
> >> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> > That non-solution is terrible. The very reason for not using deduced
> > types is to detect API breaks
On Mon, 24 Aug 2020 at 10:50, Mathias Hasselmann
wrote:
>
> Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development:
>
> On 23/08/2020 16:06, Marcel Krems wrote:
>
> If they keep using int there could be a lot of warnings like this one:
> warning: implicit conversion loses integer precisi
On Fri, 24 Jul 2020 at 22:24, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > A few years ago, Gtk threatened to do that starting with Gtk 4:
> > https://lwn.net/Articles/691131/
> > https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
> > https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0
On Fri, 24 Jul 2020 at 18:10, Thiago Macieira wrote:
> Can I suggest that we prepare at least two papers for the standard? One for
> the member-to-containing-object trick and the second for what QProperty really
> is: sub-scope of a class. We don't want a different this pointer, we just want
> to
On Fri, 24 Jul 2020 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 23 Jul 2020 at 23:59, Thiago Macieira
> wrote:
> >
> > On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > > I think the primary environment where a transition and resulting BC
>
On Thu, 23 Jul 2020 at 23:59, Thiago Macieira wrote:
>
> On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > I think the primary environment where a transition and resulting BC
> > breakage would be annoying is the Linux system environment with gcc. This
> > is where Olivier’s solutio
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer wrote:
> With the current design, notational convenience doesn’t work either:
>
> auto text = qAction->text;
> text.left(10); // booh
>
> ‘text’ is not a QString, but a QAction::_qt_property_api_text object, with
> broken... everythings.
>
>
> And i
On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
wrote:
>
> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira
> wrote:
> >
> > On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
> > > A very significant goal of this exercise is achieving notational
> >
On Tue, 21 Jul 2020 at 22:12, Thiago Macieira wrote:
>
> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
> > A very significant goal of this exercise is achieving notational
> > convenience. Theoretical concerns about UB
> > in the presence of papers that a
On Tue, 21 Jul 2020 at 16:19, Volker Hilsheimer wrote:
> object->property = newValue;
>
>
> is not possible with this, but having to write
>
> object->setProperty(newValue);
>
> like we do today can’t be a blocker for the entire concept of bindable and
> lazily evaluted properties.
A very signif
On Mon, 20 Jul 2020 at 19:09, Thiago Macieira wrote:
>
> On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote:
> > On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote:
> > >I am not going to accept a null-pointer dereference in there. The
> > >static_cast(nullptr)-> must go.
>
On Sun, 19 Jul 2020 at 21:52, Thiago Macieira wrote:
>
> On Sunday, 19 July 2020 08:20:01 PDT Thiago Macieira wrote:
> > 1. Revert the feature.
> > 2. Write papers to add necessary functionality to C++23, like reversing a
> >pointer-to-member-object back to the containing object
> > 3. Require
On Sun, 19 Jul 2020 at 15:25, Oswald Buddenhagen
wrote:
> (side effects of) actual optimizations are by definition not intentional
> belligerence. (one would, however, expect that entire chunks of code
> being thrown away would result in a warning that informs about
> specifically that (and not ju
On Tue, 16 Jun 2020 at 21:04, Matthew Woehlke wrote:
> >> Because all KDE applications will have to get ported to Qt 6 soon.
> > Why?
> ...because if they aren't, they won't get security fixes. (Because Qt 5
> is no longer maintained. Note that "LTS" isn't maintenance for Free
> Software, because
On Tue, 16 Jun 2020 at 20:27, Kevin Kofler wrote:
>
> Edward Welbourne wrote:
> > Kevin Kofler (16 June 2020 12:08)
> >> What "shiny new features"? All that a real-world application such as
> >> KWrite really needs from the operating system has been there at least
> >> since the 1990s, possibly si
On Tue, 9 Jun 2020 at 10:35, Ville Voutilainen
wrote:
>
> On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote:
> >
> > FWIW the configuration mechanism seems a bit less friendly so far with all
> > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote:
>
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build. But there is cmake-gui, which generates
> checkboxes for all th
On Sat, 23 May 2020 at 04:01, Thiago Macieira wrote:
>
> On Friday, 22 May 2020 02:21:29 PDT Tony Sarajärvi wrote:
> > Hi
> >
> > Now open for discussion: https://bugreports.qt.io/browse/QTQAINFRA-3745
> >
> > Based on Thiago’s comment that we don’t want to keep supporting it for
> > years:
> > ht
On Fri, 22 May 2020 at 20:43, Jason H wrote:
>
> How about I just pay - which my company already does? The lagging mobile
> support has us considering moving away from Qt. I think this decision would
> confirm our direction and only hasten our departure from the Qt ecosystem.
Please tell me whe
On Fri, 22 May 2020 at 17:19, Jason H wrote:
> I object, and wish multimedia to remain an essential part of Qt.
Then help maintain and develop it. Wishes are cheap.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/lis
On Tue, 19 May 2020 at 16:02, Val Doroshchuk wrote:
>
> Hi all,
> Just small update that Qt Multimedia is going to be moved from essentials
> modules to Add-On on Marketplace for Qt 6.
> More information will be announced a bit later.
With what license?
__
On Fri, 15 May 2020 at 13:45, Lars Knoll wrote:
>
> Thanks for writing this up Tor Arne. +1 for the general plan from my side.
+1 good plan. I have recently been scratching my head about where
platform-specific qtbase utilities should
go, like facilities to convert Qt containers into Java Arrays
On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø wrote:
>
>
>
> > On 13 May 2020, at 10:12, Edward Welbourne wrote:
> >
> >> Note that adding the QString(char16_t*) constructor introduces this
> >> ambiguity for the functions that are already overloaded on
> >> QString+QStringView (and thus today ar
On Wed, 13 May 2020 at 12:46, Marc Mutz via Development
wrote:
> In the not so hypothetical case that Qt is used to visualize results of
> some business calculations, chances are that thrid-party libraries will
> use std::string or std::u16string, and not QString, requiring the use of
> QString::f
On Wed, 13 May 2020 at 12:37, Marco Bubke wrote:
> auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
> AFAIK you can say that a rvalue should not return a reference by using
> ref-qualified member functions.
> View getView() const & { return v;}
However,
whatever_fu
On Sat, 25 Apr 2020 at 17:45, André Pönitz wrote:
> What I see here is a general-purpose random-access container with cheaper
> insertion and deletion at front and in the middle than *vector provides for
> 61.3% of the types, augmented by a small-object optimization that kicks in
> with zero overh
On Tue, 28 Apr 2020 at 10:59, Giuseppe D'Angelo via Development
wrote:
> > What I see here is a general-purpose random-access container with cheaper
> > insertion and deletion at front and in the middle than *vector provides for
> > 61.3% of the types,
>
> This cannot be claimed as a closed resul
On Mon, 27 Apr 2020 at 10:10, Alberto Mardegan
wrote:
>
> On 23/04/20 14:57, Ville Voutilainen wrote:
> > QVector is certainly closer to std::vector than QList is to std::list.
> > Vector isn't a really good name either,
> > for people recently taught in elemen
On Fri, 24 Apr 2020 at 13:58, Edward Welbourne wrote:
>
> Giuseppe D'Angelo (24 April 2020 10:19) asked
> >>> Which "one year release approach" are we talking about here?
>
> On 4/24/20 12:36 PM, Edward Welbourne wrote:
> >> That would be Vitaly's proposal to have major releases yearly.
>
> Giusep
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote:
>
> On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
> >> Moving to one year release approach doesn't equal to make Qt less stable.
>
> Ville:
> > Of course it does, if we now allow API breaks every year.
>
> Not necessarily: if we *allow* API break
On Fri, 24 Apr 2020 at 00:13, Vitaly Fanaskov wrote:
> How often do you think we can play this game until people look for
> something they consider more stable?
>
> Moving to one year release approach doesn't equal to make Qt less stable.
Of course it does, if we now allow API breaks every year.
On Thu, 23 Apr 2020 at 14:28, André Pönitz wrote:
>
> On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> > On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
> > >
> > > Almost all the time I second your positions, but not this time ;)
> > >
1 - 100 of 292 matches
Mail list logo
