Il 09/06/22 01:48, Thiago Macieira ha scritto:
d) Because if this, code using QStringConverter with non-builtin encodings will leak resources unless it's recompiled for 6.4. No source changes are necessary. I am saying that (d) is an acceptable situation because of (a) and (b), and in spite of (c).
So basically this is a soft ABI break?Code currently using QStringConverter on a non-UTF encoding is failing (but not leaking anything). Same code with an upgraded Qt will work, but will leak memory (how much? once per QStringConverter object? once per encoding?); a recompilation is needed to stop the leak.
I'm not really sure how much QStringConverter is used _directly_ by client code, but a random search shows that the number is not zero:
https://lxr.kde.org/ident?v=kf5-qt5&_i=QStringConverter&_remember=1
I'm also concerned that this won't pass Alpha review without adding more APIs around. How exactly do I set a QStringEncoder/Decoder with a custom encoding on top of a QTextStream, QSettings, etc.?
With these two concerns combined, I'm close to -1 this idea.(I'm perfectly fine with adding a (Qt-private) way for the XML classes to deal with non-UTF encodings, but that's not sufficient, is it?)
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
