From: Interest [mailto:interest-bounces+scott=towel42....@qt-project.org] On Behalf Of Thiago Macieira Sent: Friday, December 22, 2017 1:22 PM
On sexta-feira, 22 de dezembro de 2017 17:21:24 -02 Scott Bloom wrote: > I was able to track down the issue. > > Typically, I was writing to a QString, for some reason, there is an > undocumented difference in the writer for QString vs QIODevice writing. It's not really undocumented. QString is UTF-16, so it requires no encoding. QIODevice is 8-bit, so it encodes. ===== Completely disagree. The documentation clearly states the encoding is written out, and its not. That is a problem. The assumption is that the QString will be the final destination, that assumption is not documented, and not always true. If its not true, the client of the call, will potentially have a bug in their code, depending on how the QString is used later on. Which is exactly what happened to me. There is no explanation why a QBuffer vs QString would produce different XML. For QA purposes, our XML generating classes, always had the internal "generate XML to a string" function so that we didn't have to create any IO in our unit testing. I clearly see, to create proper XML that supports UTF-16 encoding, I needed to use a "Generate XML to an QIODevice*" methodology, since QIODevice create a proper XML file, and QString does not.. Not a problem, but completely undocumented. Scott _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
