On 2017-05-24 18:40, Thiago Macieira wrote:
On Wednesday, 24 May 2017 02:04:36 PDT Lars Knoll wrote:
> On 24 May 2017, at 00:35, Giuseppe D'Angelo <[email protected]> wrote:
>
> On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira
>
> <[email protected]> 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 a (private) macro centrally and using it in those
> places, as it has been proposed?
+1 on that. It avoids the uglyness of having a complicated #ifdef that
we'd
probably have in multiple places. It'll also ensure we can do the
changes
now and the we won't forget to fix it when we move over to Qt 6.
"We won't forget when we move to Qt 6" is not an argument. Just add the
necessary ### Qt6 macro and we won't forget.
The ### Qt5 that remained in Qt5 weren't because we forgot. It's
because they
were too difficult to apply or broke too much when applied.
I maintain that they were forgotten. Well, or ignored.
From a quick grep in QtBase, two that caught my eye:
- qvector.h: The solution is obvious, straight-forward, and BiC:
unexport QPolygon(F). Wasn't done. Wouldn't've broken anything.
- qregexp.cpp: They're also about removing const: from member
functions, this time. Code breaks, but is trivial to fix.
If we don't even remember to do _that_ kind of trivial change, how can
we, with a straight face, claim that we will handle all the ### Qt 6
ones? There are already 236 "### Qt 6" instances today, in QtBase alone.
They all need to be looked at, understood, maybe re-evaluated, and
implemented. The ones protected with QT_VERSION checks, otoh, will
become active the day Ossi flips the switch and calls dev 6.0.0.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
