Jammer-Thread

[Jörg]

Ein Instancing-Shader geht nicht. PIX stuerzt ab beim Debuggen und captured bei Verwendung von UserMarkers das falsche Frame. Und dann kann das REF-Device keine R32G32F offscreen surfaces erzeugen. :x Wird eine lange N8.

[Krishty]

Ich Depp habe die statische Code-Analyse nur im Debug-Build durchführen lassen. Da im Debug-Modus Iterator-Debugging aktiviert ist, ist ein dereferenzierter Nullzeiger in die Release-Version durchgerutscht, in der es dann durch Umstände, die im Debug-Build nicht aufgetreten waren, gekracht hat.

Ich hasse es, wenn sowas Fundamentales wie ::std::auto_ptr nur im Debug-Modus sicher ist. Pure Idiotie.

Und nun ist der RC gerade einen Tag deinstalliert; die ersetzende Professional Edition bietet Code-Analyse nicht an. -.-

[Schrompf]

No cocky attitude out of ulfjorensen please.

Wenn ich den Typen noch lange ertragen muss, passiert ein Unglück.

[kimmi]

Vielleicht würde das UNglück helfen :)...

Gruß Kimmi

[Aramis]

Beeindruckend – bezeichnet auf oeffentlichen MLs erstmal deren Admins als anmaßend, nach dem er gefuehlte 50 Threads im Forum gefuellt hat bis er ueberhaupt den Subscribe–Button fuer besagte ML gefunden hat … :-)

[kimmi]

Wir sollten einen speziellen Link für ihn einfügen: da kann er dann direkt nach /dev/null posten und wir haben Ruhe!

Kimmi

[klickverbot]

Irgendwo habe ich mal einen Text über die drei (?) Typen von Codern gelesen, die Open-Source-Projekten am meisten schaden, und ich bin mir ziemlich sicher, dass eine der Beschreibungen ganz gut auf mick-p zutrifft. Jetzt müsste ich mich bloß an die URL des Artikels erinnern… ;)

Anyway, ich glaube, ich sollte mich auch mal in die Diskussion einmischen – vielleicht flamed er mich ja dann auch bald an. xD

[Krishty]

Manchmal ist mein Hass nicht mehr in Worte zu fassen.

A.png (2.89 KiB) 12614 mal betrachtet

[eXile]

So … irgendwann wurde es auch mal Zeit … und zwar Zeit, dass nun auch ich mal etwas zu jammern habe! Also! Vielleicht kennt ihr die tolle Präprozessordefinition _SECURE_SCL. Oder auch nicht, denn standardmäßig ist diese Definition aktiv, d.h. _SECURE_SCL=1, und das bewirkt, dass die C++-STL-Implementierung von Visual C++ sogenannte „Checked Iterators“ benutzt, also das Programm standardmäßig terminiert wird, wenn ein Iterator komische Sachen macht. Ich selber habe mich darum bisher noch nie gekümmert, denn es ist doch eigentlich super, dass man standardmäßig mehr Sicherheit bekommt.

Allerdings hat mir _SECURE_SCL in der letzten Woche wirklich das Leben schwer gemacht. Hintergrund: Ich benutze manchmal Matlab, und man kann für Matlab auch Funktionen direkt aus C/C++-Code kompilieren lassen. Mein Code benutzte unter anderem die OpenEXR-Library, um OpenEXR-Bilder mit Matlab laden zu können. Natürlich war OpenEXR „standardmäßig“ kompiliert worden. Ich kompiliere also meinen kleinen Code, der zu einer Matlab-Funktion kompiliert werden soll, und rufe die Funktion in Matlab auf. Peng. Matlab abgestürzt.

Also gehe ich der Sache auf den Grund: Ich kompiliere meine Matlab-Funktion mittels des Flags -g, um mir eine PDB generieren zu lassen, und meinen Code zu debuggen. Alles läuft super, bis ein Aufruf an die OpenEXR-Library geht, welche eine std::map zurückgibt (ich kann auch den Code in der OpenEXR-Library sehen, da ich sie auf dem System selber kompiliert hatte). Vor dem return ist alles in Ordnung, die Map hat ungefähr sechs Elemente, und nach dem return meldet der Debugger wahlweise 0 oder 42238212 Elemente in der std::map, je nachdem, ob ich mit der Debug- oder Release-Version der OpenEXR-Library linke.

Zeitsprung, fünf Stunden später. Ich zweifle so langsam an meinen Fähigkeiten, und zweifle auch irgendwie daran, dass die Grundsätze der Physik für meinen Code doch eigentlich noch gelten sollten. Oder Matlab benutzt einfach einen improbability drive, was ja nie auszuschließen ist. Nunja, ich hätte ja nicht die Einleitung über _SECURE_SCL geschrieben, wenn es damit nichts zu tun hätte ;). Ich entdeckte den -v-Flag als Verbose-Schalter für die Kompilierung unter Matlab, und siehe da: Auf der Kommandozeile wurde mit _SECURE_SCL=0 kompiliert. Das machte mich sofort skeptisch, und ich schmiss Google an:

When changing _SECURE_SCL from its default setting, certain rules need to be followed. These rules are logical consequences of the fact that _SECURE_SCL changes the representations (including the sizes) of STL objects.

The first rule is that _SECURE_SCL must be consistently set throughout each translation unit (a translation unit is a source file and all of its included header files, which is compiled into an object file). That is, _SECURE_SCL can't be changed in the middle of a translation unit. The easiest way to follow this rule is by defining _SECURE_SCL on the command line (or in your project settings) instead of in source files/header files.

The second rule is that _SECURE_SCL must be consistently set in all of the object files that are linked into a single binary (EXE or DLL). Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes. (In technical terms, _SECURE_SCL mismatch is a One Definition Rule violation.) This rule applies to static libraries (which are simply packages of object files).

The third rule is that _SECURE_SCL must be consistently set among binaries (EXEs/DLLs) that pass STL objects to each other. If a DLL has a C or COM interface, nobody can tell what _SECURE_SCL setting it was built with, but if the DLL uses STL objects in its interface, then the mismatch rule applies.

Ihr könnt euch wahrscheinlich meinen damaligen Gemütszustand nun denken … :lol:. Die Bezeichnung „incomprehensible crashes“ trifft es voll. Also kann man eigentlich sagen, wer _SECURE_SCL=0 und _SECURE_SCL=1 mischt, wird sofort gesteinigt und gevierteilt. Auf jeden Fall kompilierte ich nun OpenEXR sofort mit _SECURE_SCL=0 durch, und wunderbarerweise klappte alles wie am Schnürchen. Ich kann nun endlich EXR-Bilder in Matlab laden, ohne sie mühsam konvertieren zu müssen.

Und die Moral von der Geschicht': _SECURE_SCL=0 und _SECURE_SCL=1 mischt man nicht! ;)

[Krishty]

Ja, das Iterator-Debugging ist so eine Sache. Beim Konvertieren meiner Projekte auf VS 2010 (wo _SECURE_SCL afaik ins, zum Glück aussagekräftigere, _ITERATOR_DEBUG_LEVEL geändert wurde) hat das schon richtig gekracht.
Ist bei mir immernoch täglich ein Thema, weil VS beim Batch-Build regelmäßig die Debug- und Release-Versionen durcheinander schmeißt. Echt fantastisch. (Den Fehler gibt es nicht erst in VS 2010. Das ist nur die erste Edition, bei der daraus ordentliche Warnmeldungen statt unerwarteter Crashs resultieren.)

[Krishty]

Boah, D3D9 bringt mich echt um den Verstand.

Mal ganz abgesehen von diesem ganzen Mist, dass nichts standardisiert ist und man eine million Caps prüfen muss um ein Dreieck rendern zu können (was mich jetzt schon Tage gekostet hat) -- was sich ja halbwegs durch die Evolution der Adapter entschuldigen lässt -- ist die Art und Weise, wie man das tun muss, einfach nur katastrophal. Es ist schlicht nicht möglich, Enumerationen und Kompatibilitäts-Checks halbwegs objektorientiert zu kapseln ohne furchtbaren Overhead schlucken zu müssen. (Ob die Grafikkarte ein Format unterstützt sagt einem nicht die Grafikkarte, sondern das D3D-Objekt, dem man Index und Betriebsmodus der Grafikkarte übergeben muss?!? Welcher OOP-Legastheniker denkt sich sowas aus?!?)

Das Render-State-System produziert soviel Scheiße dass man sich beim Debuggen fühlt wie das Klo von Otti Fischer bei Bierschiss. Dazu kommen so grobe Patzer wie, dass VS 2010 mit Debug-Runtime auf D3D9-Hardware nicht nutzbar ist (stürzt ab), was die Benutzung der D3D9-Debug-Runtime (die daran übrigens erhebliche Mitschuld trägt weil sie sich nur global aktivieren oder deaktivieren lässt) nur sporadisch zulässt. Von den Qualen, die einen erwarten, wenn man im Linear Space rendern möchte, mal ganz zu schweigen. Achja PIX ist auch etwa so ein Beispiel an Zuverlässigkeit wie Lindsay Lohan an Enthaltsamkeit.

Ich wünsche dieser missgeborenen Drecks-API einen schmerzhaften, aber zum Wohle der Welt möglichst schnellen Tod und hoffe dass alle, die noch freiwillig damit arbeiten (was bei einer fast-60-%-Verfügbarkeit von D3D10 nicht mehr allzu viele sein dürften) irgendwann zur Besinnung kommen und damit dazu beitragen, die Grafikwelt von dieser Pest zu heilen.

[Jörg]

Schneller Tod? Dann sollte sich MS zu "Schluss damit, kein Unterstuetzung mehr fuer Versionen <Direct3D 10. Fuer alles andere habt ihr ja VM's ...." durchringen und jedem OS ein gratis-XP beilegen. Glaubst Du auch an den Osterhasen oder blau-gruen gestreifte Gespenster? Man könnte ja Wetten abschliessen, wie lange es noch fest im OS bleibt. Laufen eigentlich DirectX-3-Spiele noch? ;)

[Krishty]

Dass MS keine Kompatibilität abknipsen sollte steht hier nicht zur Debatte … ich meine vor allem den Tod auf Seite der Anwendungsentwickler. Schließlich kriegst du heute auch zurecht nirgends mehr ein brauchbares SDK für DirectX 3-7 …

… wer sich heute noch trotz Wahlmöglichkeit für D3D9 entscheidet ist entweder sadomasochistisch, lernfaul oder ewiggestrig. Natürlich braucht man es für die XBox – dann soll MS es eben ausschließlich mit dem XNA-Framework oder in einem XBox-SDK ausliefern. Natürlich gibt es Programme, deren Zielgruppe kein D3D10+ hat – dann sollen die dafür halt bis in alle Ewigkeit das Februar-2010-SDK benutzen (Updates für XNAMath braucht diese Sparte doch eh nicht, oder?). Aber nehmt um Himmelswillen D3D9 aus dem aktuellen SDK, damit die Leute endlich ihren Arsch hochkriegen …

… ich weiß, dass ich hier schon eine ganze Zeit mein D3D10+-Fantum zur Schau trage, aber nach drei Jahren purem D3D10/11 ist D3D9 nicht nur schlimmer, als ich es in Erinnerung hatte, sondern schlimmer, als ich es mir vorstellen konnte. Als hätte ein nuklearer Holocaust unsere ganze Hochtechnologie ausgelöscht und das einzige, was das EMP überlebt hat, war ein Windows-98-Rechner mit GeForce 4 MX. Ich kriege echt die Krise … kann doch nicht sein, dass meine Ansprüche so gestiegen sind.

[Schrompf]

Nanana... ich glaube, Du machst einfach was falsch. Ich bin doch recht zufriedener DX9-Benutzer und kann Deine Hasstiraden so nicht teilen.

[Krishty]

Du hast ja auch nie länger mit D3D10+ gearbeitet, oder? Ich fand XP auch ganz toll. Damals.

[Schrompf]

Nun, grundsätzlich finde ich die DX10-API auch im Längen konsequenter und angenehmer. Ich teile nur Deine intensive Abneigung gegen DX9 nicht. Ich mag auch nicht die Hälfte meiner Zielgruppe einbüßen und bleibe daher bei DX9. Vorerst :-)

Aber mal nebenbei gefragt: arbeitest Du gerade für Deinen Wettbewerbsbeitrag mit DX9?

[Zudomon]

Aber mal nebenbei gefragt: arbeitest Du gerade für Deinen Wettbewerbsbeitrag mit DX9?

Haha... jetzt haste ihn bestimmt voll erwischt... bist du denn auch fleißig dabei?

[Krishty]

Naja, nach Steam-Hardware-Survey haben 62 % D3D10 und 33 % D3D9 – eher ein Drittel deiner Zielgruppe … also mach dir nicht zu spät Gedanken ;)

Aber mal nebenbei gefragt: arbeitest Du gerade für Deinen Wettbewerbsbeitrag mit DX9?

Exakt. Wenn die Vorgabe ein Vista-Rechner mit D3D9-Hardware gewesen wäre, hätte ich D3D11 im Techlevel-9-Modus gefahren, dafür mein Framework benutzen können und wäre nun schon fast fertig. Aber so hänge ich nach einer Woche immernoch an den Caps fest.

[Schrompf]

@Zudomon: Ja, ich bin fleißig dabei, soweit es die Zeit zulässt. Allerdings mit ein paar versteckten Trümpfen :-) Und unter Benutzung unseres hauseigenen Frameworks, dass sich bislang größtenteils sehr gut der Aufgabe gewachsen zeigt.

@Krishty: Ich würde eben jenes Framework auch stressfrei mit Dir teilen, aber ich vermute, es genügt Deinen Anforderungen nicht. Und ich persönlich hätte auf die Anforderungen hier geschissen, wenn sie ein derartiges Hindernis darstellen. Unser Beitrag wird z.B. die 10MB-Downloadgrößen-Begrenzung sprengen... wie schlimm das zu bewerten ist, überlasse ich dann halt den Zuschauern, aber aufhalten tut mich das nicht.

Du hast übrigens Recht: meine "50%-Verlust"-Angabe ist inzwischen veraltet, sehe ich gerade. Wenn nicht ein paar Leute aus unserem Team dazu gehören würden... und wenn ich soviel Zeit für eine komplette Restrukturierung hätte... dann wär das doch toll! Ist es aber nicht.

[Krishty]

@Krishty: Ich würde eben jenes Framework auch stressfrei mit Dir teilen, aber ich vermute, es genügt Deinen Anforderungen nicht.

„Es genügt meinen Anforderungen nicht“ im Sinne von „ich bin zu stolz, Hilfe anzunehmen“ ;)

Und ich persönlich hätte auf die Anforderungen hier geschissen, wenn sie ein derartiges Hindernis darstellen. Unser Beitrag wird z.B. die 10MB-Downloadgrößen-Begrenzung sprengen... wie schlimm das zu bewerten ist, überlasse ich dann halt den Zuschauern, aber aufhalten tut mich das nicht.

Nein, so will ich das nicht machen … was einen nicht umbringt macht einen nur härter. Solange ich meine Wut über D3D9 hier abreagieren kann, muss ich es nicht im Beitrag tun, indem ich auf die Regeln pfeife.

[Schrompf]

@Krishty: Ich würde eben jenes Framework auch stressfrei mit Dir teilen, aber ich vermute, es genügt Deinen Anforderungen nicht.

„Es genügt meinen Anforderungen nicht“ im Sinne von „ich bin zu stolz, Hilfe anzunehmen“ ;)

Nein, eher "Es erreicht bei weitem nicht die Perfektion in Sache Code-Qualität, die Du sonst anzustreben scheinst.". :-)

[Krishty]

Warum kriegt es kaum jemand gebacken, eine vernünftige BMP zu schreiben? Dass BITMAPFILEHEADER::bfSize bei den meisten Programmen falsch ist, ist ja noch zu verschmerzen. Dass aber so eindeutig definierte Konstanten wie BITMAPINFOHEADER::biSize von Gimp und Photoshop verhauen werden macht es einem wirklich schwer, die Programme noch ernst zu nehmen … warum nicht gleich eine falsche Magic Number schreiben …

[Aramis]

Die BMP–Dokumentation ist selber das exakte Gegenteil einer sauberen Spezifikation – tausende unnuetze Features und Felder, deren Bedeutung im Nirvana verschwunden ist, oder nur von Windows irgendwo intern gebraucht werden.

Was erwartest du da eigentlich? :-)

[Krishty]

Stimmt. Aber wenn in der Spezifikation steht, das Feld habe immer mit 40 anzufangen, muss man doch schon arg was missverstehen, um da 56 hinzuschreiben … ist doch wirklich keine Rocket Science …

Edit: Welcher Schwachsinnige ist eigentlich dafür verantwortlich, dass wir in den letzten Jahrzehnten nur BGR benutzt haben? Welche Niete war danach noch so blöd, den Alpha-Kanal hinten dran zu klemmen? Und was haben die sich dann noch dabei gedacht, das im D3DFORMAT „ARGB“ statt „BGRA“ zu nennen?!? Das kann doch nur böse Absicht sein, oder?!? Genau wegen sowas hasse ich D3D9 …

Edit II: Wirklich schade, dass D3D9 unter XP keine 1-Bit-Texturen unterstützt. Gerade von einer API, die noch aus der „guten alten Zeit“ entstanden ist, hätte ich Unterstützung effizienter Formate erwartet … in D3D10 kann man durch die komplette Anwendung hindurch, angefangen bei Vertices und aufgehört bei Lookup-Tables, 25 bis 50 % Bandbreite sparen einfach weil es effizientere Formate (mit 1, 4 oder 8 Bits in brauchbaren Kombinationen) gibt (in D3D9 kann man auch 8- oder 16-Bit-Komponenten für Vertices definieren, aber steht dann wieder vor der Kompatibilitätskeule. Und an bitweises Entpacken von Vertexkomponenten kommt es nicht ran). D3D9 hatte über seine Lebenszeit scheinbar doppelt soviele Formate wie DXGI – die waren aber wohl zum Großteil nicht nur überflüssig sondern auch furchtbar ineffizient. Uuuuh, D3D10 unterstützt kein treibergesteuertes AAA … dafür kann es acht mal soviele Pixel in eine gleich große Alphamap packen …

[Seraph]

Du musst viel ruhiger werden und das alles etwas lockerer sehen. ;)

[Krishty]

Wie, bin ich etwa nicht ruhig? Dann warte noch ein paar Wochen, bis der Druck bei der Action wirklich ins Unermessliche steigt und alles, was selbst ich selber im Moment noch als Belanglosigkeit abtue, zu einem Kardinalproblem hochstilisiert wird. Dieser Thread steht bei mir jetzt sowieso unter am meisten aktiv in – und gemäß „ist der Ruf erst ruiniert, lebt es sich ganz ungeniert“ wird er dann auch ordentlich vollgeschaufelt. Das hier wird das reinste Geplänkel dagegen sein. Ihr könntet mir eigentlich auch einen Mecker-Feed mit Alterskontrolle einrichten, den ich dann minütlich vollfluche …

Die letzten beiden Stunden hatte ich wieder mit was feinem zu tun: Kompiliert man mehr als eine Quelldatei, treten plötzlich ganz neue Linkerfehler auf als bei einer einzigen! Doppelt definierte Symbole, die sich nur dadurch beheben lassen, dass man sie ein drittes Mal definiert(!). Irgendwer hat da seinen Job nicht getan … aber genau, wenn man in der Klemme sitzt, die Logik versagt und Analysen nichts mehr bringen, geht man es ruhig an. Steckt uns ja schon seit Jahrmillionen in den Genen mit Fluchtreflex, Panikreaktion und Nervenzusammenbruch.

[Aramis]

Ihr könntet mir eigentlich auch einen Mecker-Feed mit Alterskontrolle einrichten, den ich dann minütlich vollfluche …

Ich kann dir einen Twitter-Account einrichten. Interesse? :-)

[Krishty]

Ich kann dir einen Twitter-Account einrichten. Interesse? :-)

Sobald ich sowas in die Hände kriege, maule ich nicht mehr nur über die Idiotie in der Programmierung, sondern breche auch alles über Social Media und Web 2.0 aus, was im Moment noch still in mir vor sich hinrottet … dann komme ich ja zu garnichts mehr :(

[Jörg]

Warum macht es C++ einem so schwer? :

Code: Alles auswählen

struct A {
	float x[4];
	float y;
};

template<unsigned long long int x> struct T {
	static void f() {;}
};

void g() {
	T<(unsigned long long)&(((A*)0)->y)>::f();
	T<(unsigned long long)(((A*)0)->x)>::f();
}

Comeau bockt, VC schluckt die Haelfte, g++ mags auch net.
Wie kann man das umgehen?

[Lord Delvin]

Warum macht es C++ einem so schwer? :

Code: Alles auswählen

struct A {
	float x[4];
	float y;
};

template<unsigned long long int x> struct T {
	static void f() {;}
};

void g() {
	T<(unsigned long long)&(((A*)0)->y)>::f();
	T<(unsigned long long)(((A*)0)->x)>::f();
}

Comeau bockt, VC schluckt die Haelfte, g++ mags auch net.
Wie kann man das umgehen?

Sieht so aus, als wüsstest du entweder nicht genau, was du schreiben willst oder du machst es dir unnötig schwer. Sind irgendwie viel zu viele Klammern.