Port endl to \n
Details
Diff Detail
- Repository
- R238 KDocTools
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Will be better if you use QLatin1Char('\n'), "\n" will call strlen on which is unneeded. Also QStringLiteral is missing on some strings.
Isn't it better to just use Qt::endl ?
I think it's much clearer to understand Qt::endl than QLatin1Char('\n')
But if we prefer to change to use \n it should be merged into the existing strings, doesn't make much sense to do
outStream << "</l:i18n>" << QLatin1Char('\n');
instead of
outStream << "</l:i18n>\n';
No, it's not. It's namespaced in Qt 5.15 means it should be ifdef guarded which makes things to suck.
"No, it's not. It's namespaced in Qt 5.15 means it should be ifdef guarded which makes things to suck." yep it's for that I switched to "\n"
I don't want to add #ifdef if it's not necessary.
"/compile/kde5/framework/frameworks/kdoctools/src/docbookl10nhelper.cpp: Dans la fonction « int writeLangFile(const QString&, const QString&, const LangListType&) »:
/compile/kde5/framework/frameworks/kdoctools/src/docbookl10nhelper.cpp:62:57: erreur: « endl » n'est pas un membre de « Qt »
62 | .arg(dtdPath) << QLatin1Char('\n') << Qt::endl;
"
no it's not :) qt5.13 :)
Ah, it works fine in 5.14.
I was going to say we must report to Qt immediately that they broke source compatibility and that was unacceptable but then i realized that the old non namespaced version works just fine, it's just deprecated.
I'm going to go back to party preparations :)
I agree with Albert here; I think it's a bit more painful but it's probably going to be cleaner.