On 12/06/2019 18.14, Matthew Woehlke wrote:
> On 22/05/2019 12.41, Konstantin Tokarev wrote:
>> In the latter QList can be replaced with
>> std::vector> or QVector>
>
> No, it can't. `QList` has value semantics w.r.t. `T`. Your
> "alternatives" have pointer semantics.
And, to be clear... while ha
(Sorry for not chiming in earlier, this was hidden wy at the top of
my spool where I didn't notice there were unread messages.)
On 22/05/2019 09.49, Lars Knoll wrote:
> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for
On 03/05/2019 15.13, Thiago Macieira wrote:
> On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote:
>> Anyhow, I too feel that we may need a dedicated smart pointer class for
>> this, to catch all the corner cases and allow the existing flow of
>>
>> 1) create something
>> 2)
Am 12.06.19 um 12:45 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor
> wrote:
>> On 6. Jun 2019, at 16:48, Christian Gagneraud wrote:
>> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote:
>> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
>> On Fri, 7 Jun 2019 a
On 6/12/19 10:28 AM, Mutz, Marc via Development wrote:
> On 2019-06-12 09:20, Ulf Hermann wrote:
>>> I don't think that (non-)COW is a problem in the scenario under
>>> discussion.
>>
>> Having the thing COW makes the porting simpler at the cost of suboptimal
>> performance. If we wrote a C
On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor wrote:
> On 6. Jun 2019, at 16:48, Christian Gagneraud wrote:
> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote:
> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote:
> Am 06.06.19 um 15:52 schri
On 11/06/2019 22:13, André Pönitz wrote:
Can we at the very least agree that each party is allowed to use the
same*pattern* of reasoning in this discussion, no matter on how
much merit we see in the individual argument?
I'd rather avoid using any logical fallacy when possible, instead of
doub
Mutz, Marc via Development wrote:
> This is a bit like the Fridays for Future generation clash: the new
> developer asks "why is there Q_FOREACH if there's ranged-for?" and the
> older devs answer: "because I wants my SUV, erhm, I mean Q_FOREACH".
The difference is that Q_FOREACH does not destroy
On 2019-06-12 08:23, Philippe wrote:
On Wed, 12 Jun 2019 07:54:29 +0200
Nicolas Arnaud-Cormos via Development
wrote:
Whenever Qt is adding a new feature there's a teachability issue that
needs to be handled. Any duplication with the C++ standard adds
cognitive load to students.
One could dis
On 2019-06-12 09:20, Ulf Hermann wrote:
I don't think that (non-)COW is a problem in the scenario under
discussion.
Having the thing COW makes the porting simpler at the cost of
suboptimal
performance. If we wrote a COW container as a drop-in replacement for
QMap or QHash with equival
Even if modules were available (and stable) in at least mainline versions
of {clang, gcc, msvc} in a year (which I don't think they will), Qt would
have to get modularized to actually be able to reap the benefits of modules
(given the strong feelings in the "deprecations" thread, we can expect
mid-
> I don't think that (non-)COW is a problem in the scenario under
> discussion.
Having the thing COW makes the porting simpler at the cost of suboptimal
performance. If we wrote a COW container as a drop-in replacement for
QMap or QHash with equivalent behavior we could just s/QMap/QFlat
12 matches
Mail list logo
