On 20 March 2017 at 16:19, Marc Mutz <marc.m...@kdab.com> wrote:
>> And if I want to run the same code with Qt 5 and Qt 6? I don't want to
>> modernize it,
>> since that may change or break what it does on Qt 5, and I also don't
>> want to modernize code
>> as part of my build in a dynamic fashion, because that costs time and can
>> cause version control problems. If we want Qt to be a library that caters
>> to various different
>> user scenarios, we should first stop assuming that one-way
>> modernization tools are
>> a realistic solution to compatibility problems.
>
> That from someone that just broke an awful lot of lines of C++ code by making
> noexcept be part of the function type :P

Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm
not entirely convinced
it broke "an awful lot of lines of code", and it indeed specifically
did not and does not break very
vast swaths of existing code, because *every* function call still
behaves as they did before,
although certain pointer conversions don't. It certainly doesn't
produce a fear that
it would break "the whole world".

> Well, seriously. My answer is the same: Time has only one direction. Qt source
> and binary compatibility only has one direction. If you want to use Qt in a
> way it was not intended to be used, then you need to pay the prize, and not
> ask the community to do so for you.
>
> You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt 6.
> You can define your own MyQListOrQVector type alias. Or you can #ifdef. It's
> up to you.


That's great, but before I have migrated all my code to any of those,
it's simply better
to change QList to be a QVector, fix the cases that require reference
stability (which you're
already doing in some places) to use a different type, deprecate
direct uses of QList
and *then* _eventually_ remove QList altogether, rather than doing it
without any grace
period.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to