Wobei es die Frage ist, was davon an Qt liegt und was am C++-Compiler. Nicht nur der GCC (insbesondere der g++/libstdc++) hat sich ja mit den Jahren um Größenordnungen gewandelt, die Binaries egal welcher Art inkompatibel machen. Wenn du den selben C++-Compiler nebst Stdlib und anderen Abhängigkeiten nimmst, mit dem du damals die Qt1 übersetzt hast, dann sollte das mit der Kompatibilität auch bei C++ hinhauen. Allerdings ist es dann meist doch
Nein. Das habe ich in de.c.l.py schon mal diskutiert, deswegen nur kurz: C++ ändert das Speicherlayout wenn man zB neue private Variablen einführt und dabei nicht höllsich aufpasst. Und das bei gleichem compiler. Damit bricht man binärkompatiblität - trolltech selber hat dazu mal einen Aufsatz verfasst, der erläutert wie man da vorgehen muss um das zu verhindern. Und das ist nicht zwischen Major revisions machbar. Sie habe wenn das API soweit mit Compatiblitätslayern versehen, das man eine alte Qt2-App noch unter 3 zum laufen bekommt - durch einen Compilationbslauf, und mit (verhältnismässig) wenig Änderungen. Was alles übrigens ein guter grund sein kann, C-style interface zu verwenden für eine Bibliothek, auch wenn sie intern mit C++ geschrieben wurde.
Aber ist auch egal, ich werde den Nachweis ohnehin nicht antreten. Eigentlich hat die Diskussion auch nichts auf der Python-Mailingliste zu suchen, da wäre dann die Kompatibilität von PyQt wichtiger. Und die ist dann wieder eine ganz andere Geschichte...
Das ist insofern von belang, als das pyQt ja für eine bestimmte Version kompliliert wurde. Wenn was du sagst stimmen würde, dann könnte man PyQT 3.x ja für Qt-1 benutzen usw. Und das geht eben nicht. Aber wenn man zusammen geschnürte Pakete nimmt, dann hat man damit natürlich nix zu tun. Und zumindest für den Desktop ist ja auch eigentlich nur noch Qt3 von Belang. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de