Startseite / Publikationen / Mobile / Qt-Framework / QT-Framework 4.7: Fehlermeldung "Unescaped backslashes are deprecated"
Seit QT 4.6 haben sich einige Änderungen am QT-Framework ergeben.
Eine vom Compiler erzeugte Fehlermeldung ist wie folgt:
WARNING: c:\Nokia\QtSDK\Simulator\Qt\mingw\lib\qtmaind.prl:1: Unescaped backslashes are deprecated.
In der angegebenen Datei ersetzt man die einfachen Backslashes durch doppelte Backslashes: so wie es da steht!
"Unescaped backslashes are deprecated."
Heisst: "Nicht mit einem Escape-Zeichen versehene Escape-Zeichen sind veraltet."
Das ist nicht immer sofort einsichtig, denn oft sieht der Fehler schwieriger aus, als seine Beseitigung ist oder man sieht den Wald vor Bäumen nicht mehr. Manchmal dauert es aber auch Tage, bis man eine entsprechende Lösung für ein Problem findet.
Aus:
QMAKE_PRL_BUILD_DIR = C:\Nokia\QtSDK\Simulator\Qt\mingw/src/winmain QMAKE_PRO_INPUT = winmain.pro QMAKE_PRL_TARGET = libqtmaind QMAKE_PRL_DEFINES = QT_THREAD_SUPPORT QMAKE_PRL_CONFIG = include_source_dir lex yacc warn_on debug uic resources incremental_off windows debug DebugBuild Debug build_pass warn_on link_prl copy_dir_files debug_and_release debug_and_release_target debug stl exceptions rtti mmx 3dnow sse sse2 simulator minimal-config small-config medium-config large-config full-config build_all debug incremental create_prl link_prl depend_includepath QTDIR_build debug DebugBuild Debug build_pass staticlib warn_on png qt_install_headers qt warn_on depend_includepath qmake_cache target_qt debug_and_release static debug DebugBuild Debug build_pass no_autoqmake staticlib static moc thread QMAKE_PRL_VERSION = 4 QMAKE_PRL_LIBS = -LC:\\OpenSSL-Win32_full\\lib
Wird:
QMAKE_PRL_BUILD_DIR = C:\\Nokia\\QtSDK\\Simulator\\Qt\\mingw\/src\/winmain QMAKE_PRO_INPUT = winmain.pro QMAKE_PRL_TARGET = libqtmaind QMAKE_PRL_DEFINES = QT_THREAD_SUPPORT QMAKE_PRL_CONFIG = include_source_dir lex yacc warn_on debug uic resources incremental_off windows debug DebugBuild Debug build_pass warn_on link_prl copy_dir_files debug_and_release debug_and_release_target debug stl exceptions rtti mmx 3dnow sse sse2 simulator minimal-config small-config medium-config large-config full-config build_all debug incremental create_prl link_prl depend_includepath QTDIR_build debug DebugBuild Debug build_pass staticlib warn_on png qt_install_headers qt warn_on depend_includepath qmake_cache target_qt debug_and_release static debug DebugBuild Debug build_pass no_autoqmake staticlib static moc thread QMAKE_PRL_VERSION = 4 QMAKE_PRL_LIBS = -LC:\\OpenSSL-Win32_full\\lib
Das hätten die Framework-Macher, d.h. Herausgeber bei Nokia (so schön das Alles ist..) auch in allen Dateien entsprechend ändern können, ohne großartig für Verwirrung (Anwendungsverhinderung bei den Entwicklern und Systemhäusern durch Zeitverlust) zu sorgen.
Das nächste mal bitte bei Einführung solcher Änderungen am Compiler, konsequente Änderungen an den Dateien gleich mit umsetzen, damit es sofort benutzbar ist - ohne Stolperstein für den Entwickler. (Länderübergreifend kooperative Softwareentwicklung, ohne erst googeln zu müssen bis der Arzt kommt..)
Man sieht an diesem Beispiel auch sehr schön: mehr zu verarbeitende Zeichen bedeuten wieder mehr benötigte Rechenleistung.
Auch wenn es sich hierbei nur um Rechenleistung für den Kompiliervorgang auf dem Entwicklerarbeitsplatz handelt, so sind es dennoch mehr zu verarbeitende Zeichen die nicht unbedingt nötig gewesen wären. Betrachtet man das wachsen der Zeichen/ Symbole in solchen Systemen, könnte man Unmut über die benötigte Rechnerhardware (Energieverbrauch) in Zukunft generell äußern. Selbiges gilt auch bei Spielen, Anwendungen und Klicki-Bunti Betriebssystemen und derzeit schon proklamierten PC-Supercomputern. Enormer Ressourcenverbrauch also, um den Absatz anzukurbeln: wessen Absatz und vor Allem auf Kosten von wem? Dir, oder von uns allen? (Das Ankurbeln des Absatzes möchte ich den Entwicklern bei Nokia hier noch garnicht einmal unterstellen, sondern nur das ständige wachsen der Zeichen in den Systemen aufzeigen, sprich: wachsende Technologiekomplexität.)