On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira
wrote:
>
> We are arguing whether the change makes the code uglier and is worth that
> ugliness. I'm not sold on that. Leave those const behind until Qt 6, unless
> you can show that engaging the move constructor is important.
What about defining
On Tuesday, 23 May 2017 11:22:46 PDT Marc Mutz wrote:
> These are acceptable because they affect only more-or-less broken code.
> And since they are acceptable, we ought to be able to perform them
> freely, without a discussion every time. We don't discuss adding
> function overloads. We weren't ev
On 2017-05-23 16:17, Thiago Macieira wrote:
On Monday, 22 May 2017 22:26:38 PDT Marc Mutz wrote:
> if there's a chance of existing code breaking
How can removing top-level const from a return type "break" existing
code
any more than adding a function overload?
I thought we were discussing S
On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote:
> In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in
> QVector.
That is not very difficult once we move the begin pointer out of the d pointer
and into the main QVector class. We need to add an interface to QArray
On Monday, 22 May 2017 22:26:38 PDT Marc Mutz wrote:
> > if there's a chance of existing code breaking
>
> How can removing top-level const from a return type "break" existing code
> any more than adding a function overload?
I thought we were discussing Source Incompatible Changes. If it doesn't
Am Donnerstag, 18. Mai 2017, 10:58:23 CEST schrieb Ville Voutilainen:
> [...] the QUIP is here for review:
> https://codereview.qt-project.org/#/c/194984/
Thanks,
(Sorry for not replying to the QUIP, but discussions on gerrit are not so easy
to follow)
Here are what what are the characteristic
Am Dienstag, 23. Mai 2017, 11:17:32 CEST schrieb Ville Voutilainen:
> On 23 May 2017 at 12:00, Marc Mutz wrote:
> >> Maybe, but I have some questions: the review for removing top-level
> >> consts
> >> from QRegion says "It has no effect and inhibits move semantics." How
> >> does
> >> it inhibit
On 23 May 2017 at 12:00, Marc Mutz wrote:
>> Maybe, but I have some questions: the review for removing top-level consts
>> from QRegion says "It has no effect and inhibits move semantics." How does
>> it inhibit move semantics? How is this even a SiC? What _positive_ impact
>> do these changes hav
On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote:
> How is this even a SiC?
Just as you can detect whether a function is overloaded (taking the address
without cast fails), you can detect the const on the return value. Andre shows
the difference for QVector. A user could write something l
On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote:
> On 23 May 2017 at 11:39, Marc Mutz wrote:
> > On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote:
> >> (a detach happening on Linux, but not on MSVC)
> >
> > Don't fall for FUD.
> >
> > QPixmap does not have functions that are overloaded
On 23 May 2017 at 11:39, Marc Mutz wrote:
> On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote:
>> (a detach happening on Linux, but not on MSVC)
>
> Don't fall for FUD.
>
> QPixmap does not have functions that are overloaded on const/non-const.
> Neither does QRegion. Well, except for the special
On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote:
> (a detach happening on Linux, but not on MSVC)
Don't fall for FUD.
QPixmap does not have functions that are overloaded on const/non-const.
Neither does QRegion. Well, except for the special member functions, which is
the whole point of the ex
On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote:
> But what I dislike is the fact that we get different signatures on
> different platforms (because we can't change this on MSVC without breaking
> BC).
So... if MSVC mangles the return type, does that mean that we can _overload_
const QPixmap
marc.mutz wrote:
> On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote:
> > Then we are right now concluding this kind of change should not be in that
> > part of the QUIP.
>
> The QUIP gives an _algorithm_ to categorise SiCs, it's not a listing. There's
> a list, yes. It's called _examples_.
>
>
Am Dienstag, 23. Mai 2017, 08:36:00 CEST schrieb Lars Knoll:
> > On 23 May 2017, at 07:26, Marc Mutz wrote:
> >
> > On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote:
> >> Then we are right now concluding this kind of change should not be in
> >> that
> >> part of the QUIP.
> >
> > The QUIP
15 matches
Mail list logo
