Jammer-Thread

[eXile]

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!

[Krishty]

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.

[eXile]

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.

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:

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.

[Krishty]

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).

Wirds nicht geben, da nur Implizite Abhängigkeiten bzgl. unserer DLLs bestehen.

Ah, okay.

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

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?

[eXile]

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.

Wir editieren uns hier kaputt, kann das?

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

[Krishty]

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.

[Krishty]

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 hieraus

Code: Alles auswählen

Scene.hpp(140): error C2248: 'INonAssignable::operator =' : cannot access private member declared in class 'INonAssignable'
BasicTypes.hpp(297) : see declaration of 'INonAssignable::operator ='
BasicTypes.hpp(294) : see declaration of 'INonAssignable'
          This diagnostic occurred in the compiler generated function 'TCPublicData<Scene>::CLuminary &TCPublicData<Scene>::CLuminary::operator =(const TCPublicData<Scene>::CLuminary &)'
Strings.hpp(662): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const CUTF8String' (or there is no acceptable conversion)
          Strings.hpp(803): could be 'TCMultiByteString<CUnit> &TCMultiByteString<CUnit>::operator =(TCMultiByteString<CUnit> &&)'
          with
          [
              CUnit=Cric::CUTF8Unit
          ]
          Strings.hpp(842): or       'TCMultiByteString<CUnit> &TCMultiByteString<CUnit>::operator =(const TCMultiByteString<CUnit> &)'
          with
          [
              CUnit=Cric::CUTF8Unit
          ]
          while trying to match the argument list '(const CUTF8String, const CUTF8String)'
          This diagnostic occurred in the compiler generated function 'TCPublicData<Scene>::CLuminary &Cric::Bieder::Resources::TCPublicData<Scene>::CLuminary::operator =(const TCPublicData<Scene>::CLuminary &)'

Build FAILED.

ableiten, dass einer Klasse ein Move-Assignment-Operator fehlt?

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

[Krishty]

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.

[Alexander Kornrumpf]

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.

[Krishty]

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

[kimmi]

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

[Krishty]

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.

[Aramis]

… oder psychisch :-)

[kimmi]

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

[klickverbot]

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«

[Krishty]

Die Steuerung von Mafia II ist der letzte Dreck. Selten war etwas so schwammig, klobig, nervig … die Figur zeigt dauernd woanders hin als die Maus. Und wenn man im Zielmodus ist, ist der halbe Bildschirm von der Spielfigur verdeckt und Deckungssuche unmöglich. Wie konnte man das nur dermaßen in den Sand setzen, nachdem die Steuerung in Teil 1 so schön direkt und zugleich butterweich war?

Der nächste Punkt ist die verwaschene Grafik … ich hätte ja nie gedacht, dass ein Spiel gleichzeitig verwaschen und verpixelt aussehen kann, aber Spieleneuerscheinungen sind ja bekanntlich die Würze des Lebens. Haben die was zu verstecken, dass die über (fast) alles einen 1×1-Gauss jagen? Hätten sie die Arbeit nicht besser in eine funktionierende Anti-Aliasing-Option investieren können?

Es ist eine beispielLose Frechheit, ein Spiel nur in HD spielen zu können, weil es sonst schlicht und einfach zu verwaschen wäre, um etwas zu erkennen. Und dass es dann immernoch flimmert wie nix. Sehr schade um den meisterhaften Content … der hat es einfach nicht verdient, so kopfschmerzverursachend präsentiert zu werden … auf halbe Größe skaliert sieht es nämlich einfach umwerfend aus.

[eXile]

Sieht ja hart gefailt aus. Ist das etwa eine Konsolenumsetzung? (Dann würde das mit der schlechten Steuerung auch Sinn ergeben.)

Nachtrag: Apropos HD-Auflösung. Ich war hier mal im lokalen Computermarkt und habe mir die aktuellen Notebooks angeschaut. Welche alle wegen einer HD-Auflösung Bildschirme dem 16:9-Bildbreiten-/-höhenverhältnis haben. Und ich muss sagen: Ich kann auf solchen Teilen nicht arbeiten. Selbst wenn ich im Texteditor eine 8-Punkt-Schriftart einstelle, ist mir zu wenig Text vertikal dargestellt. Mit 16:10 konnte ich mich ja noch anfreunden, aber 16:9 ist zu viel.

Übrigens gab es auch mal einen Artikel, dass durch die Einführung der Full-HD-Auflösung kaum ein Hersteller nunmehr höhere Auflösungen entwickeln will. Auf einem 22-Zoll-Arbeitsbildschirm ist mir Full-HD aber bereits zu grobkörnig.

[Krishty]

Sieht ja hart gefailt aus. Ist das etwa eine Konsolenumsetzung? (Dann würde das mit der schlechten Steuerung auch Sinn ergeben.)

Es erscheint auch für PS3 und XBox360, und das scheint tatsächlich viel zu stark abgefärbt zu haben.

Selbst wenn ich im Texteditor eine 8-Punkt-Schriftart einstelle, ist mir zu wenig Text vertikal dargestellt. Mit 16:10 konnte ich mich ja noch anfreunden, aber 16:9 ist zu viel.

Andererseits bietet Breitbild auch die Möglichkeit, mehrere Dokumente nebeneinander zu platzieren. Mit einem horizontal dreifach gegliederten 16:9er (links Task-Leiste / Projektbrowser / Messenger, mittig Quelltext, rechts Debug-Output) habe ich effektiv mehr Code im Blick als bei 5:4, wo ich nur die halbe Höhe nutzen konnte weil gestapelt werden musste und für horizontale Anordnung zu wenig Breite da war …

[.357er-Argument]

Die Steuerung von Mafia II ist der letzte Dreck. Selten war etwas so schwammig, klobig, nervig … die Figur zeigt dauernd woanders hin als die Maus. Und wenn man im Zielmodus ist, ist der halbe Bildschirm von der Spielfigur verdeckt und Deckungssuche unmöglich. Wie konnte man das nur dermaßen in den Sand setzen, nachdem die Steuerung in Teil 1 so schön direkt und zugleich butterweich war?

Hölle, da hast Du noch kein GTAIV ohne Pad gezockt, oder? :) Kaum 25 Tasten, die man in Griff kriegen muss, nur um dann das derzeitige Gefährt im Hafenkai zu versenken, weil man aus Versehen den Radiosender gewechselt hat und das Fernlicht eingeschaltet, nachdem man den lästigen Fußgänger beim Abbiegen überfahren hat, usw... aber das Abgluckern des Autos schlägt dann wunderbar spiegelnde Wellen, die astrein von der Action-Kamera eingefangen werden, während die Spielfigur mit Nahtoderfahrung in den Wellen rumschwappt. :)

Aber in beiden Fällen (Mafia2 und GTA4) verpasst man ein großartiges Spiel, wenn man sich nicht die Mühe (sprichwörtlich) macht, sich an die Steuerung zu gewöhnen.

[Krishty]

Hölle, da hast Du noch kein GTAIV ohne Pad gezockt, oder? :)

Allein darüber, wie viele Spiele-Blockbuster ich in den letzten Jahren verpasst habe, könnte ich einen eigenen Jammer-Thread abzweigen … aber danke der Info – wenn ich die Vollversion in die Hände kriege, werde ich sie also nicht sofort in die Ecke legen sondern brav die Steuerung lernen (oder meinen PlayStation-Controller anschließen) :)

[Krishty]

Ich hasse C++. Wenn C nicht schon so früh so weit verbreitet gewesen wäre, würde es heute kaum ein Schwein benutzen … nicht, dass mir die Alternativen besser gefallen würden – ihr wisst, dass ich alle anderen Sprachen noch viel mehr hasse – aber es gibt Dinge, die einfach nicht sein müssen …

Heute hatte ich einen netten Bug, wo eine unterbrochene enum-Aufzählung

Code: Alles auswählen

enum {
    a,
    b,
    c = a,
    d, // d hat denselben Wert wie b, nicht den, der ursprünglich c zugewiesen worden wäre
};

in Verbindung mit irgendwelchem Template-Quatsch (eine undefinierte Template-Funktion wird als doppelt vorhanden angesehen, wenn man sie erst aufruft und danach spezialisiert?!?) dafür gesorgt, dass ich dem Linker 50 Template-Spezialisierungen von Hand vorsortieren durfte. Als das endlich gefixt war, funkte mir noch so ein Sequence-Point-Dreck dazwischen (modify(i).foo(i); ist was anderes als auto t = modify(i); t.foo(i);) … es gibt Tage, da sollte man garnicht erst die IDE hochfahren …

[Krishty]

Mein Programm ist im Release-Modus nur fast halb so schnell wie im Debug-Modus (170 % Ausführungszeit) – und das mit Kompiliereinstellungen, die sich sonst eigentlich immer bewährt haben. WTF?!? Der Hass!

[Schrompf]

Sending SIGBUS to "application" due to unaligned access (PC 5 PR 42c88a)

Das ganze Elend zweier Tage in einem Satz. Die Adresse kann ich ja dank MapFile zumindest noch einer Datei und Funktion zuordnen, aber keiner meiner Breakpoints vor/um diese Stelle herum zündet. Scheiß Remote Debugging.

Noch drei Wochen bis Produktionsstart.

Edit: das Grundproblem ist glaube ich die Tatsache, dass hier Code von 70 Leuten über drei Länder und vier Standorte verteilt zusammenarbeiten soll. Ich habe inzwischen eine beängstigende Sicherheit darin entwickelt, fremden Code zu debuggen.

[Jonathan]

Windows neu installiert und git geht nicht mehr. Zeigt keine History von meinen Repos mehr an und wenn ich irgendwas anderes machen will, krieg ich Fehlermeldungen ohne Text. Ich habs jetzt mittlerweile 3 mal neu installiert, in 2 unterschiedlichen Versionen. Mal sehen, ob das irgendwann wieder läuft, wäre schon praktisch...

[Biolunar]

Warum ist es denn so schwer eine vernünftige 64 Bit Version von Flash rauszubringen? Ich könnte kotzen, wenn ich unter Windows immer den 32 Bit IE starten muss um was auf youtube zu sehen... (Und: Nein, ich werde niemals auf einem 64 Bit System 32 Bit Software vorziehen.) Seit ein paar Monaten ist auch die 64 Bit Linux Version von Flash eingestellt *heul* >:-( Immerhin bekomme ich da 32 Bit Flash im 64 Bit Browser zum laufen ohne auch nur ein bisschen selbst frickeln zu müssen. Aber das kann's doch nicht sein oder? Da sieht man mal wie sch**** die proprietären Flash Versionen programmiert sind. Die freien Versionen bieten leider nicht annähernd die Performance, die teilweise nötig ist... Es ist zum Heulen.

[Krishty]

Ganz ganz toll:

Code: Alles auswählen

template <size_t Dimension> class CVector {
    float MyComponents[Dimension];
    …
public:
    float & operator [] (size_t const Index) {
        if(Index >= Dimension)
            throw exception("vector subscript out of range");
        return MyComponents[Index];
    }
};
…
template <size_t VectorsDimension> void Zero(CVector<VectorsDimension> & Vector) {
    for(size_t Dimension = 0; Dimension < VectorsDimension; ++Dimension)
        Vector[Dimension] = 0.0f;
};

Obwohl jeder Vektor-Zugriff geinlined wird und der Compiler die Schleife abrollt (der Index also bei jedem Aufruf eine Konstante ist) gelingt es dem Compiler nicht, zu erkennen, dass die Exception niemals geworfen werden wird. Im Klartext: Alle meine Mathe-Funktionen sind durchsiebt mit Exception-Auslösern, deren Auftreten schon zur Kompilierzeit ausgeschlossen werden könnte. Manchmal weiß ich nicht, was da passiert.

[Jörg]

Wechsle doch endlich mal den Compiler ;)
Der gcc vom Ubuntu 10 macht ne schön kurze Schleife draus (fuer eine Vektor-Groesse von 100), und benutzt sogar ein 4fach-SSE store zum "Einnullen". Das sollte doch reichen, um 'nen Defect-Report zu generieren bei MS.

[Aramis]

Langsam geht es mir auf den Keks. Nennt man das nicht eine Variante des Fahrradständerproblems oder so?

:D (Sorry, es *musste* einfach sein).

[Schrompf]

Und außerdem: es mag Geschmackssache sein, aber ich würde Exceptions nur werfen, wenn ich tatsächlich erwarte, dass das Programm auch ohne diese Operation sinnvoll weiterlaufen kann. Ein Array Out Of Bounds ist ein Grund, den Debugger anzuwerfen oder das Programm abzubrechen, aber weitermachen kann man da meiner Meinung nach nicht mehr. Nimm stattdessen ein Assert und das Thema Optimierungen ist für diese Ecke erledigt.

[Krishty]

@Jörg: Ja, das könnte dir gefallen! Aber warte mal ab, wenn VC 11 kommt und die meine ganzen Bug-Reports und Feature-Requests umgesetzt haben, wird GCC wieder mit links kassiert ;)

@Aramis: Warum mich die Farbe kümmern sollte? Weil das verdammte Ding dick und fett mit meiner und nur meiner Unterschrift bepinselt werden wird, darum! Wäre ja noch schöner, wenn ich vor einer bekackten Maschine kapitulieren würde …

@Schrompf: Nein, das geht nicht – solange man nicht für jeden einzelnen Aufruf nachweisen kann, dass der Parameter in Wertebereich liegt, ist die Prüfung absolut berechtigt und eine Assertion allein, die im Release-Modus einfach garnichts täte, könnte fatal enden. Das ist ja gerade das Problem – theoretisch ist der einzige, der wirklich befugt ist, die Exception zu entfernen, der Compiler. Der ist nur leider zu dumm. Und fortgesetzt werden kann das Programm u.U. doch noch; ich weiß ja vom Standpunkt des Vektors aus nicht, was der Code mal tun wird, der ihn benutzt.