ZFX + Developia

Nach einem weiteren Tag gescheiterter Implementierungsversuche eines QAbstractItemModels habe ich mich vom QAbstractItemModel abgewandt, und dafür dem klassischen QTreeWidget zugewandt. Eine Vermittlerklasse hält Datenbaum und Tree Widget synchron, ich kann ohne Indexschlacht Items einfügen, aktualisieren und löschen, kurz und einfach ist es obendrein. Ich persönlich weiß mit dem AbstractItemModel wirklich nichts anzufangen, ohne einen weiteren Hilfsbaum in der Modellimplementierung ist da offensichtlich nichts zu machen, zudem ist die Behandlung von Änderungen auf der Datenseite über die vielen Indizes bei nicht naturgemäß indizierten Daten eine Qual.

Interessante Randbemerkung: Ein Blick in den Source Code der SimpleItemModel-Klasse, die sich praktisch bedienen lässt wie ein klassisches TreeWidget, offenbart, dass diese sich fehlende Indizes stets on-the-fly per linearer Suche besorgt, bei großen Datenmengen absolut suboptimal, wie auch hier von jemand anderem festgestellt wurde. Die TreeWidget-Klasse dagegen cachet einmal bestimmte Indizes, insofern dürfte sie um einiges besser abschneiden.

Container von Heap-Objekten (sozusagen ::std::vector<::std::auto_ptr<XXX>>) sind in C++ mit das Schlimmste, was man schreiben müssen kann. Erst recht, wenn es sich dann nicht um einen Vector, sondern um ein Set handelt (die Zeiger also gleichzeitig die Schlüssel sind) – dann ist das Chaos perfekt.

Ich glaube, mal irgendwo gelesen zu haben, dass der std::auto_ptr aus verschiedenen Gründen eh nicht zu empfehlen sei. Stattdessen riet man zu boost::shared_ptr.

Naja, in Containers geht auto_ptr ja eh nicht, deswegen schreibt er wohl sozusagen. Was ist damit, die nehme ich immer: Boost Pointer Container Library (Reference)

Mein 2-hoch-zehnter Post … ach du liebe Güte. Ich habe mir geschworen, nicht zu weinen! Bleib stark!

*Tief lufthol* Also, ich möchte der Community danken … und ganz besonders denen, die ZFX letztes Jahr nochmal neu gemacht haben, denn sonst wäre das hier bloß mein 1839. Post …

… aber vor allem mir selber, denn wenn ich nicht den ganzen Tag bei alten Grey's Anatomy-Episoden und Populärmusik in der Bude hocken würde, hätte ich nie den Selbst- und Welthass aufbringen können, der mich zu so vielen Posts antreibt!
Und mein Herz ist bei all denen, die sich mein ganzes Geplärre tagein, tagaus antun. Ihr seid klasse! *Träne wegwisch*

Kann ich hier winken? Sieht das jemand? Mamaaaa! *fuchtel*


CodingCat hat recht, auto_ptr an sich geht nicht. Einen eigenen, passenden Vector pflege ich schon seit geraumer Zeit und Mit Move-Semantics ist der Array-of-Smart-Pointer-Ansatz jetzt möglich – an meinem speziellen Fall scheitert es aber daran, dass die Suchfunktion als Parameter dasselbe erwartet, was auch im Container steckt – d.h. dann habe ich wieder Shared Ownership.

Boost bleibt draußen; ich habe eben 90 % der STL rausgeschmissen und kehre den Effekt nicht wieder um, indem ich jetzt boost einbinde. Ist ja nur eine – mit dem Gesamtaufwand verglichen – kleine, wenn auch extrem nervige, Bodenwelle auf dem Pfad der Erleuchtung … sie ist keine Dampfwalze wert sondern muss mit einem Holzlöffel abgeschabt und mit dem Daumen glattgerubbelt werden.

chromanoid war geringfügig zu schnell, sonst hättet ihr jetzt 1024x768 Posts

Krishty, er lebe hoch, hoch, hoch! :D

Beim 2 hoch 20ten Beitrag miete ich persoenlich einen Schwertransporter, stelle eine Blaskapelle zur Ablenkung drauf und walze mit ihr deinen Internetzugang flach :-)

Trotzdem herzlichen Glueckwunsch zu diesem Meilenstein.

Zum 2^20ten könnt ihr mir besser Kukident und eine Packung Windeln schenken …

Das hier ist aus einem vector-template: Wenn ich das Template mit IResource * (ein polymorpher Typ) für CElement instantiere, geschieht Folgendes:
• Beim Aufrufen der Funktion zeigt NewElementsValue auf die gewollte Adresse.
• Beim Erreichen der Funktion (hier „) {“) immernoch.
• Direkt in der ersten Zeile der Funktion (hier „…“, aber egal, was da steht) ändert sich die Adresse … allerdings nur in Debug-Builds. Die neue Adresse zeigt irgendwo hin wo die eigentliche Adresse ein paar Bytes weiter im Speicher liegt.

Kann mir jemand erklären, was da passiert? Ich muss zugeben, dass ich mit RValue-Referenzen noch ein wenig wackelig bin.

Edit: Okay, das ging schnell. Ich hatte bei der Übergabe ::std::move durch reinterpret_cast<IResource * &&>(NewElement) ersetzt; es muss aber static_cast<IResource * &&>(NewElement) heißen. Der Compiler scheint RValue-Referenzen in Debug-Builds als Datenstrukturen aus vier Bytes aufzubauen; darum hat es gekracht. (Die STL ist übrigens ein toller Lehrer, die macht nur C-Style-Casts …) Warum aber beim Erreichen der Funktion immernoch der korrekte Wert angezeigt wurde, weiß ich jetzt nicht … geholfen hat es nicht … als ich die Chose aber reproduzieren wollte, funktionierte eine direkte Übergabe magischerweise; so kam ich drauf.

Warum muss Memory Management mit der CRT in C++ nur so kompliziert sein? Aber vielleicht helfen die Beobachtungen ja dem ein oder anderen, insbesondere der letzte Absatz könnte interessant sein. :-)

In consequence, many sources suggest that you never ever share complex types across module boundaries altogether, which would indeed be the most simple and elegant way to overcome these issues without further caution and thinking.

Oder man linkt halt statisch. Noch simpler, und schneller, und erlaubt statisch gelinkte CRT. Schau an.

Richtig, aber dann hat man keine Dlls. :-)

Stimmt :-) Solange das der Wunsch ist, muss man das halt in Kauf nehmen. Aber ich wollte doch die Gelegenheit nicht auslassen, meinem alten Steckenpferd - dem statischen Linken - mal wieder Gehör zu verschaffen.

Nebenbei:

Mitglieder in diesem Forum: Alexander Kornrumpf, Aramis, Chromanoid, kimmi, Lynxeye, MSN [Bot], Schrompf und 1 Gast

Wer hier jammert, wird praktisch nur von Moderatoren wahrgenommen :-)

Dass ich mal fünf Minuten nicht aktualisiere, heißt nicht, dass ich nicht lese ;)

ZFX. Von Moderatoren für Moderatoren? Aber nein, das würde unserem Haupt-Content-Sponsor Krishty nicht gerecht. ;-)

Sternzeit WTFBBQSAUCE Komma Drei. Nachdem ich mich nun wieder meinem früheren DLL-Problem zugewandt habe (welches ich erfolgreich in der Zwischenzeit verdrängt hatte), konnte ich es nun auch lösen. Defacto war die verbleibende Lösung ganz simpel: Man muss sicherstellen, dass immer die Debug-Exe auch nur Debug-DLLs und die Release-Exe auch nur Release-DLLs lädt, und wirklich alle diese Dateien eingebettete Manifeste besitzen.

Übrigens, wenn man die zlib aus dem Quellcode baut, sind keinerlei Manifeste eingebettet. Und die Debug- und Release-DLLs heißen gleich. Damit ist Ärger schon vorprogrammiert.

Kurzum: Ich habe alle DLLs so umbenannt und neu kompiliert, dass die Debug-Versionen ein angehängtes „d“
im Vergleich zur Release-Version besitzen. Und natürlich überall Manifeste einbinden lassen. Nun funktioniert auch alles, und es werden immer die richtigen Libraries geladen. DLL-Hell has finally frozen over!

eXile hat geschrieben:Ich habe alle DLLs so umbenannt und neu kompiliert, dass die Debug-Versionen ein angehängtes „d“ im Vergleich zur Release-Version besitzen.

Wäre es nicht einfacher gewesen, sie in eigene Verzeichnisse zu kompilieren? Du brauchst für x86/x64 ja sowieso getrennte Verzeichnisse, warum also nicht auch bin x64d und bin x86d?
Wenn irgendwann ein DLL-Name aus einer Config oder der Kommandozeile kommt (statt hardgecoded zu sein), darfst du einen Mechanismus einbauen, der an Dateinamen mit der Endung .exe oder .dll automatisch d anhängt … oder brauchst gar getrennte Ressourcen für jede Version. Dann bricht erstmal die echte Hölle los.

Krishty hat geschrieben:Wäre es nicht einfacher gewesen, sie in eigene Verzeichnisse zu kompilieren? Du brauchst für x86/x64 ja sowieso getrennte Verzeichnisse, warum also nicht auch bin x64d und bin x86d?

Das Problem ist, dass manche Programme hier mehr als 3 GB an eigenen DLLs brauchen. Da ist rumkopieren nicht mehr drin, sondern der Pfad zum DLL-Ordner kommt in den Benutzerspezifischen PATH. Der x86/x64-Problematik gehe ich elegant aus dem Weg, indem ich nur x64-Anwendungen kompiliere, und auch sonst keine x86-Anwendungen auf jene DLLs zugreifen müssen.

Krishty hat geschrieben:Wenn irgendwann ein DLL-Name aus einer Config oder der Kommandozeile kommt (statt hardgecoded zu sein), darfst du einen Mechanismus einbauen, der an Dateinamen mit der Endung .exe oder .dll automatisch d anhängt … oder brauchst gar getrennte Ressourcen für jede Version. Dann bricht erstmal die echte Hölle los.

Wirds nicht geben, da nur Implizite Abhängigkeiten bzgl. unserer DLLs bestehen. Außerdem verliert man damit Funktionalität, denn:

http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx hat geschrieben:DLLs often have complex interdependencies that implicitly define the order in which they must be loaded. The library loader efficiently analyzes these dependencies, calculates the correct load order, and loads the DLLs in that order.

Wenn man LoadLibrary und Konsorten benutzt, versteht der Loader das natürlich nicht, und wenn die DLL dann auch noch weitere eigene DLLs auf solchem „dynamischen Wege“ laden soll, kann man das schon gar nicht mehr in DllMain machen, weil sonst ein Deadlock entstehen könnte.

eXile hat geschrieben:Das Problem ist, dass manche Programme hier mehr als 3 GB an eigenen DLLs brauchen.

Wow. Darf ich fragen, was das für Anwendungen sind? Außerdem: Bei mir sind Debug-Builds fünf bis zehn Mal so groß wie Release-Builds, artet das Laden nicht zu stundenlangem Swapping aus (selbst, wenn das ein Hochleistungssystem mit 32+ GiB RAM ist)? Ach ja, falls es hilft, kann man auch explizit Pfade angeben, wo Windows zuerst nach DLLs suchen soll (der Vollständigkeit halber).

eXile hat geschrieben:Wirds nicht geben, da nur Implizite Abhängigkeiten bzgl. unserer DLLs bestehen.

Ah, okay.

eXile hat geschrieben:Außerdem verliert man damit Funktionalität, denn:

http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx hat geschrieben:DLLs often have complex interdependencies that implicitly define the order in which they must be loaded. The library loader efficiently analyzes these dependencies, calculates the correct load order, and loads the DLLs in that order.

Wenn man LoadLibrary und Konsorten benutzt, versteht der Loader das natürlich nicht, und wenn die DLL dann auch noch weitere eigene DLLs auf solchem „dynamischen Wege“ laden soll, kann man das schon gar nicht mehr in DllMain machen, weil sonst ein Deadlock entstehen könnte.

Ich folge bei DLLs Single-Point-of-Truth und radikaler Kapselung, d.h. meine DLLs haben eigentlich keine Querabhängigkeiten … darum hatte ich mit solchen Problemen jetzt nicht wirklich gerechnet. Ist aber in der Tat ein riesiger Vorteil von Automatisierung.

Wir editieren uns hier kaputt, kann das?

Krishty hat geschrieben:

eXile hat geschrieben:Das Problem ist, dass manche Programme hier mehr als 3 GB an eigenen DLLs brauchen.

Wow. Darf ich fragen, was das für Anwendungen sind? Außerdem: Bei mir sind Debug-Builds fünf bis zehn Mal so groß wie Release-Builds, artet das Laden nicht zu stundenlangem Swapping aus (selbst, wenn das ein Hochleistungssystem mit 32+ GiB RAM ist)?

Naja, stellt dir einfach vor, das Programm lädt alle Libraries die es zu Szene-Graphen, Datei- und Bildformaten, Kompressionsalgorithmen, Statistikprogrammen, Linear-Algebra-Packages, Optimierungsverfahren einmal auf der CPU und einmal für CUDA, Mikrokontrollerlibraries und Visualisierungstoolkits, die du dir vorstellen kannst. Ich glaube, das kommt ganz gut hin. Auch besitzen (lustigerweise) nicht alle von uns erstellten DLLs Debuginformationen, so dass auch im Debug es bei ca. 4 bis 5 GB bleibt.

Krishty hat geschrieben:Wir editieren uns hier kaputt, kann das?

… sein? Ja, deswegen geh ich erstmal ins Bett! ;)

Danke. Jetzt habe ich wieder dieses am-falschen-Ende-gespart-Gefühl (meine Sternendemo ist mittlerweile von 650 auf 110 KiB runteroptimiert, und ihr schiebt problemlos 5 GiB durch den Loader …) :D GN8.

Wenn nicht bald default- und delete-Functions kommen, drehe ich noch durch. Dass C++0x ohne Concepts kommt, ist die größte Enttäuschung, die mir diese Sprache in den letzten Jahren beschert hat. Oder könnt ihr hierausableiten, dass einer Klasse ein Move-Assignment-Operator fehlt?

Achja, Cpp-Formatierung weil ich nicht weiß, wie ich sonst eingerückten Text beibehalten kann.

Schade, dass Windows 7 offenbar nicht das „Der Grafiktreiber hat nicht mehr reagiert und wurde zurückgesetzt“-Verhalten übernommen hat – eine Endlosschleife in einem Shader hat eben mein System irreversibel einfrieren lassen. Dass das so geht, beängstigt mich jetzt irgendwie.

Hmm, mit CUDA und Win7 hab ich das „Der Grafiktreiber hat nicht mehr reagiert und wurde zurückgesetzt“-Verhalten schon mal erlebt. Nur so als Datenpunkt.

Dann hat ATI es verkackt. Schade. (Geschah in einem D3D-10-Pixel-Shader.)

Das ist wahrscheinlich ein Bug im Kernelspace des ATI-Treibers. ich habe so etwas in der Art schon beim CodeAnalyst feststellen müssen, da der Profiler ebenfalls Filtertreiber installiert, um die Daten profilen zu können. Schick den ATI-Jungs doch einfach den Dump, dann können sie das fixen.

Gruß Kimmi

Was für einen Dump? Die Maschine ist eingefroren und nach 30 Sekunden habe ich den Strom gekappt.

Mir fiel gerade ein, dass das Problem auch im Shader-Compiler liegen könnte … es wurde nämlich noch kein Fenster angezeigt … wäre aber auch andererseits ziemlich sonderbar, wenn der im Kernel-Space liefe.
Ich habe auch ehrlich gesagt keinen Bock, da irgendwas zu reproduzieren – da ist dann ein ganzer Tag vorbei ehe ich einen Repro-Case isoliert habe und am Ende geht noch physisch was kaputt.

… oder psychisch :-)

Bei Windows laufen mehr Sachen im Kernelspace als man vermuten sollte :) ( unter anderem der Windowsmanager sprich der Fensterzusammenbauer, wenn ich mich richtig erinnere ). Und wenn der keinen Dump schreibt: selber schuld.

Gruß Kimmi

Die Kombination aus der hier und da noch nicht ganz runden Toolchain von D und Template-Metaprogramming führt ab und an zu bemerkenswerten Fehlermeldungen. Im Moment versuche ich gerade rauzufinden, was hier falsch läuft: »Undefined symbol: _D3qtd3MOC171__T11genFuncDefsS48_D3qtd3MOC7newSlotFAyaAyaZS3qtd3MOC11FunctionDefS48_D2ad10MainWindow10MainWindow13slot_openFileMFZvS49_D2ad10MainWindow10MainWindow14slot_closeFileMFZvZ11genFuncDefsFZAS3qtd3MOC11FunctionDe«