Jammer-Thread

[Krishty]

Ausnahmebehandlung ist doch ein Wulst, das gibt es garnicht. Visual C++’ Implementierung datiert auf 1993 zurück – ist also fast so alt wie ich; bloß hat sie sich weniger entwickelt. Zum Glück gibt es auch viele Artikel darüber, wie Visual C++’ Ausnahmebehandlung im Detail funktioniert.

Dummerweise sind die aber alle für Windows x86. Für x64 wurde Windows’ Ausnahmebehandlung (zum Glück!) komplett überarbeitet, dafür findet man aber nun leider weniger Informationen über die Funktionsweise; und wenn man denen glaubt, ist die MSDN-Doku über die API für x64-Ausnahmebehandlung bestenfalls lückenhaft, wenn nicht schlicht und einfach falsch.

Und zu guter letzt muss ich noch in Kauf nehmen, dass der Kram fester mit dem Compiler verklebt ist als ein Obdachloser mit seinen Unterhosen – was bedeutet, dass ich eine MS CRT-spezifische Implementierung rausschmeiße um sie durch eine Visual C++-spezifische Implementierung zu ersetzen.

Was am Ende des Tages (jeden Tages) bleibt, ist die Einsicht, dass alles von Grund auf ineffizient, überladen, fehleranfällig und hässlich ist; und es zynisch vom Schicksal ist, dass überhaupt irgendein Programm irgendwo jemals richtig funktioniert oder zumindest gehalten hat.

[Krishty]

C++’ Umgang mit Konstanten ist doch von vorn bis hinten verkackt. Sehen wir uns mal das hier an:

float3 projectedPosition = project(…);
if(0.0 < projectedPosition) {

Huch – 0.0 statt 0.0f geschrieben. Maschinentext:

movd        xmm0,dword ptr [rsp+50h]
cvtps2pd    xmm0,xmm0
comisd      xmm0,mmword ptr [__real@0000000000000000]
jbe         func+30Dh

Was ich wollte:

movss       xmm0,dword ptr [rsp+50h]
comiss      xmm0,dword ptr [__real@00000000]
jbe         func+309h

Doppelte Latenz; kein Mucks vom Compiler. Ist doch zum Kotzen dieser ganze implizite Scheiß in C++.

Klar; unter x86 wäre es natürlich egal gewesen weil da eh alle Gleitkommaberechnungen mit 1000 Bits laufen und die CPU erstmal hundert Takte lang das FPU-Status-Word auf dem Stapel seziert hätte oder so. Aber der x64-Boost fällt halt nur noch halb so groß aus, weil die CPUs typempfindlich geworden sind.

[dot]

0.0 ist eben ein double und kein float ;)
Der Compiler tut also genau was du wolltest, wenn du was anderes wolltest hättest du ja 0.0f geschrieben :P

[CodingCat]

Die Idee hinter Hochsprachen ist doch, dass der Compiler bei Leichtsinnsfehlern gerade nicht das tut, was du ihm sagst, sondern dich möglichst auf den Fehler hinweist. ;)

Anderes Thema: Ich bastle gerade wieder an meiner String-Kodierungsumwandlung. Es ist ja schon irre, was sich mit Templates und Deduktion alles anstellen lässt. Wären da nicht immer die vielen notwendigen Funktionsweiterleitungen, von denen ich wegen String-Rückgabetypen mit Sicherheit weiß, dass VC++ unfähig sein wird, auch nur die trivalsten zu inlinen. :x

[dot]

Evtl. hilft perfect forwarding?

[CodingCat]

Nein, da hilft nur ein neuer Compiler, der vernünftig inlinen kann, auch wenn der Rückgabetyp einen Destruktor hat. :(

Wenn ich ganz viel Zeit hätte, könnte ich das Ding so umschreiben, dass bei den Weiterleitungen stets Funktionen mit Rückgabe über Referenzparameter aufgerufen werden, aber dafür kodiere ich dann doch zu wenig um.

[CodingCat]

Ich will, ich will, ich will! using struct MyStruct; in Funktionen! :(

[CodingCat]

Warum sollte die Berechnung von String-Hashes in der STL nicht auch an die Standard-Allokatoren gebunden sein?
Ach richtig, partielle Spezialisierungen gibts ja erst seit gestern!

Code: Alles auswählen

template<>
	class hash<_STD string>

STL, Y U NO ...

Code: Alles auswählen

template<class Traits, class Alloc>
	class hash< _STD basic_string<char, Traits, Alloc> >

[kaiserludi]

Code: Alles auswählen

	JString& JString::operator+=(int aNum)
	{
		JString str;
		str = aNum;
		return *this += str;
	}

knallt mir im Marmalade GCC ARM für Windows beim ausführen von str = aNum; mit einem Segmentation Fault weg und zwar, weil er bei

Code: Alles auswählen

	JString& JString::operator=(int aNum)
	{
		EG_CHAR buffer[12];
		SNWPRINTF(buffer, sizeof(buffer), L"%d", aNum);
		delete[] Buffer;
		GetBuffer(Length=WCSLEN(buffer));
		WCSCPY(Buffer, buffer);
		return *this;
	}

in der letzten Zeile die Rücksprungadresse nicht mehr findet und sich die executable scheinbar beim Versuch des Rücksprungs in einer Endlosschleife verfängt. In der Unix Implementation von Marmalade GCC ebenfalls für ARM bekomme ich stattdessen jeweils einen EXC_BAD_ACCESS, den ich allerdings noch nicht näher untersucht habe.

Die Implementierung

Code: Alles auswählen

	JString& JString::operator+=(int aNum)
	{
		EG_CHAR buffer[12];
		SNWPRINTF(buffer, sizeof(buffer)/sizeof(EG_CHAR), L"%d", aNum);
		return *this += buffer;
	}

hingegen funzt problemlos.

Die Version von weiter oben aber bereitet weder MSVC noch Clang noch dem Standard GCC Probleme, weder bei Build für X86, noch für ARM, nur der Marmalade GCC Compiler mag sie nicht.

Bug im Compiler/Linker oder sind die anderen Compiler einfach nur so nett, mir was durchgehen zu lassen, was der Standard nicht definiert und ich seh einfach nicht, was?

[CodingCat]

Code: Alles auswählen

	JString& JString::operator=(int aNum)
	{
		EG_CHAR buffer[12];
		SNWPRINTF(buffer, sizeof(buffer), L"%d", aNum);
		delete[] Buffer;
		GetBuffer(Length=WCSLEN(buffer));
		WCSCPY(Buffer, buffer);
		return *this;
	}

Das sieht ziemlich seltsam aus. Ich rate einfach mal, dass GetBuffer() dir in Buffer den Zeiger auf ein neu alloziiertes Array der übergebenen Länge Length = WCSLEN(buffer) in Buffer schreibt. In diesem Fall kriegst du einen Buffer Overrun, weil WCSCPY() dir zusätzlich noch eine terminierende Null in den Puffer schreibt, die in Length nicht mit eingerechnet ist.

Wer immer der Autor des Codes ist, empfiehl ihm mal etwas sequenzielleren / weniger nebenwirkungsbehafteten Code. Ausnahmesicher ist der Code übrigens auch nicht, wenn GetBuffer() eine Ausnahme wirft, hast du anschließend unweigerlich inkonsistenten Zustand und irgendwann vermutlich ein Doppel-delete. ;-)

[kaiserludi]

GetBuffer() sieht so aus:

Code: Alles auswählen

	inline void JString::GetBuffer(unsigned int MaxStrLen)
	{
		Buffer = new EG_CHAR[(BufferLen=MaxStrLen)+1];
	}

Mit der von dir angesprochenen Zeile ist also alles in Ordnung. Es gibt keinen Bufferoverrun, weil die terminierende Null mit eingerechnet ist (die Methode wird so an dutzenden Stellen benutzt und das funzt immer einwandfrei).
Die Klasse und auch die gesamte restliche Codebase nutzen keine Exceptions, von daher ist Ausnahmesicherheit kein Thema. Was meinst du mit nebenwirkungsbehaftet? Dass GetBuffer() mit einer Zuweisung des Rückgabewertes von WCSLEN() an eine lokale Variable aufgerufen wird? Andere Nebenwirkungen sehe ich da nicht und diese ist so primitiv, dass sie kein Problem darstellt.

[CodingCat]

Naja, für Zeilen wie GetBuffer(Length=WCSLEN(buffer)); und Buffer = new EG_CHAR[(BufferLen=MaxStrLen)+1]; gibt es absolut keinen Grund. Im besten Fall verschleiern sie die Ausführungsreihenfolge und machen den Code unleserlich, im schlimmsten Fall wird der Code falsch, wie z.B. bei function(assignment1, assignment2), in welchem Fall die Ausführungsreihenfolge tatsächlich undefiniert wäre.

Abgesehen von derlei Nebenwirkungen durch übermäßige Schachtelung von Ausdrücken verstehe ich auch nicht, wieso die Methode GetBuffer() heißt. Der Name ist nur irritierend, weil die Funktion überhaupt nichts zurückgibt. Stattdessen verändert die Methode das Objekt, was für Get-Methoden wiederum eher unerwartet ist.

[CodingCat]

Back to topic: Entscheidend könnte auch sein, dass du SNWPRINTF() im einen Fall die Buffer-Größe, im anderen die Anzahl der Characters im Buffer übergibst. Eins von beiden ist definitiv falsch, sofern dein Wide-Character nicht nur 8 Bit hat. ;-)

[kaiserludi]

Naja, für Zeilen wie GetBuffer(Length=WCSLEN(buffer)); und Buffer = new EG_CHAR[(BufferLen=MaxStrLen)+1]; gibt es absolut keinen Grund. Im besten Fall verschleiern sie die Ausführungsreihenfolge und machen den Code unleserlich, im schlimmsten Fall wird der Code falsch, wie z.B. bei function(assignment1, assignment2), in welchem Fall die Ausführungsreihenfolge tatsächlich undefiniert wäre.

Abgesehen von derlei Nebenwirkungen durch übermäßige Schachtelung von Ausdrücken verstehe ich auch nicht, wieso die Methode GetBuffer() heißt. Der Name ist nur irritierend, weil die Funktion überhaupt nichts zurückgibt. Stattdessen verändert die Methode das Objekt, was für Get-Methoden wiederum eher unerwartet ist.

Randnotiz: Entscheidend könnte auch sein, dass du SNWPRINTF() im einen Fall die Buffer-Größe, im anderen die Anzahl der Characters im Buffer übergibst. Eins von beiden ist definitiv falsch, sofern dein Wide-Character nicht nur 8 Bit hat. ;-)

function(assignment1, assignment2) ist nur problematisch, wenn die Ausführungsreihenfolge der beiden aissignments zueinander eine Rolle spielt und damit wohldefiniert sein muss, ansonsten darf dieser Code undefiniert sein.
ich persönlich finde solche primitiven Verschactelungen einfach weit übersichtlicher als Extrazeilen, weil unnötige Extrazeilen dafür sorgen, dass weniger in dem Zusamenahng wesentliche Zeilen auf en Screen passen. Solange das ganze compilerunabhängig das macht, wonach es aussieht ohne böse Überraschungen und es nur erwünschte, nicht aber unerwünschte Nebenwirkungen gibt, bevorzuge ich möglichst kompakten Code.

Dass die Methode GetBuffer() heißt, verstößt tatsächlich gegen unsere Namenskonventionen, nicht nur wegen dem einem Getter widersprechenden Verhalten, sondern auch, weil Methodennamen im Gegensatz zu Klassen pascalCase und nicht etwas CamelCase verwenden sollten, aber der Methodenname stammt noch aus der Zeit, bevor ich das Projekt übernommen habe und auch nach mehreren Jahren bin ich noch lange nicht restlos dazu gekommen, alle Namen sinnvoll zu gestalten, das ist einfach eine Never Ending Story bei Legacy Code, in dem jede einzelne von tausenden Methoden einer anderen Konvention folgt.

Die Randnotiz ist ein ganz heißer Tipp. Das habe ich doch tasächlich noch gar nicht gesehen gehabt. Da sind die Implementationen von MSVC, Clang und GCC wohl zu wohlwollend, das einfach problemlos zu schlucken. Ich vermute mal, das ist der Bug. Kann ich aber erst morgen testen.

[kaiserludi]

Ja, die Übergabe der size in bytes statt in characters war in der Tat das Problem :)

[Krishty]

Bah. Deklariert man in Visual C++ eine Funktion __declspec(noreturn), wird hinter jedem Aufruf der Funktion ein int 3 eingesetzt um auch wirklich sicher zu gehen, dass die Funktion nicht zurückkehrt.

Als ob man das nicht schon zur Kompilierzeit sicherstellen könnte.

Ähnliches gilt übrigens auch für __assume(false); da landet das int 3 in den toten Zweigen. Nee; __assume(false) erzeugt keinen Text. Wo tf kommen denn dann die int 3s her, die VC selbst dann einsetzt, wenn weder __declspec(noreturn) noch __assume(false) in der Nähe sind?!…

[Krishty]

Wenn ich mein Programm starte, hat es 13 Threads:

• Drei TppWorkerThreads, die die ganze Zeit nur warten;

• Neun Threads, die vom AMD-Treiber angeschubst wurden; und

• meinen Thread.



D3DCREATE_DISABLE_PSGP_THREADING unterdrückt die neun Treiber-Threads; drückt die Leistung allerdings auch auf 60 %. Zwei oder drei der Threads haben also tatsächlich sowas wie eine Daseinsberechtigung. Bäääh.

[CodingCat]

We recommend that you install Visual Studio versions in the order in which they were released. For example, install Visual Studio 2008 before you install Visual Studio 2010.

Somit habe ich mich wohl gerade unfreiwillig für immer von Visual Studio 2005 verabschiedet.

(Und das VS2010-Setup nimmt kein Ende, da stehen nochmal so viele Pakete Schlange wie er bis jetzt bereits installiert hat.)

[j.klugmann]

Wieso kann das MSVC-Team nicht endlich mal den aktuellen GCC in VS2010 integrieren, anstatt den eigenen ungepflegten, veralteten Compiler für viel Geld zu verkaufen?! Ich will endlich auch unter Windows modernes C++ schreiben können!

[antisteo]

Wieso kann das MSVC-Team nicht endlich mal den aktuellen GCC in VS2010 integrieren, anstatt den eigenen ungepflegten, veralteten Compiler für viel Geld zu verkaufen?! Ich will endlich auch unter Windows modernes C++ schreiben können!

Allein schon daran, dass der MSVC-Compiler mehr Geld kostet, siehst du, dass er besser ist. GCC ist zu langsam taugt nix. Kauf dir lieber einen richtig professionellen Compiler.

[j.klugmann]

Falls die Performance wirklich allumfassend besser sein sollte, dann ist mir das dennoch egal, da das akute Projekt auf das ich mich bezogen habe, nicht so performance-relevant ist. Ich lebe viel lieber mit eingeschränkter Performance als mit einem kaum implementierten Standard. Außerdem lässt sich die Qualität eines Produkts nicht in seinem Preis messen. Zusätzlich sollte man nicht pauschal von "besser" oder "schlechter" sprechen, sondern die Vor- und Nachteile differenziert betrachten...

[Krishty]

Denkst du, dass jemand, der LLVM einsetzt und in der Signatur für Ubuntu wirbt, eine kostet-nix-taugt-nix-Aussage ernst meinen würde? ;)

(Was nicht heißt, dass ich GCC in irgendeiner Weise verteidigen würde.)

[j.klugmann]

Hatte ich ein Moment drüber nachgedacht, aber irgendwie war ich mir nicht so ganz sicher, insofern habe ich seine Aussage erstmal ernstgenommen. :P

[Schrompf]

Um das Ganze mal auf die fachliche Ebene zurückzuholen: welche Teile des Standards werden denn vermisst? Ich schiele immer neidisch auf Range Based Loops und Strong Enums, aber auch der ganze Spaß rund um Konstruktor-Umleitungen usw. wäre interessant.

[kimmi]

Eure Sorgen möchte ich haben. Wir dürfen uns hier auf einer Plattform mit einem Compiler von 2002 / 2003! vergnügen! Und der Prozess, neue Compiler benutzen zu dürfen, ist komplexer als das Deutsche Steuerrecht.

Gruß Kimmi

[CodingCat]

Um das Ganze mal auf die fachliche Ebene zurückzuholen: welche Teile des Standards werden denn vermisst? Ich schiele immer neidisch auf Range Based Loops und Strong Enums, aber auch der ganze Spaß rund um Konstruktor-Umleitungen usw. wäre interessant.

• Variadic Templates: Erst mit Variadic Templates wird Perfect Forwarding vollständig, und new in Anwendercode kann endlich delete in die ewigen Jagdgründe folgen. Außerdem hört mit emplace_back() endlich diese elende Kopiererei beim Einfügen von Elementen in Container-Objekte auf. Hier war das VC++10-Team sogar zu faul, einen halbwegs vernünftigen Ersatz zu bieten. (Ich habe mir mit viel Makromagie beholfen, damit ich auch in VC++10 so etwas wie Variadic Templates und ein halbwegs ordentliches emplace_back() habe.)

• Constexpr: Wie Krishty schon mehrfach gezeigt hat, ist VC++10 noch immer absolut unfähig, die trivialsten Berechnungen (oder Konstruktionen!) bei der Initialisierung statischer konstanter Daten zur Compile-Zeit auszuführen, und so unsinnigen dynamischen Initialisierungscode wegzuoptimieren. Und das, obwohl der Compiler dazu prinzipiell problemlos in der Lage sein sollte, bei nicht-statischen Daten ist er es schließlich auch. Schon einfachste starke Typisierung von POD-Werten mittels Templates (z.B. durch Einheiten) ist in VC++10 ohne constexpr bei großen Mengen von Konstanten keinesfalls zu empfehlen.

• Auf range-based for und stark typisierte Enumerationen freue ich mich natürlich ebenfalls, wenngleich diese für das entstehende Programm am Ende keine derartige Relevanz besitzen. Sehr schade finde ich hierbei, dass die STL nicht mit range-based Algorithms nachgezogen hat, aber dafür hätte es wiederum Concepts bedurft ...

[j.klugmann]

Dank CodingCat, das sind genau die Punkte, die mich am meisten nerven. Besonders Variadic Templates würde ich gerne mit der neuen Version begrüßen können, aber laut diversen Blogs wird das wohl auch nichts... *grummel*

[Schrompf]

Anscheinend haben wir dann doch sehr verschiedene Anforderungen an die Programmiersprache. Ich will primär Ergebnisse erhalten, ich habe ehrlich gesagt den erzeugten Code noch nie angeschaut. Demzufolge finde ich die kleinen Erleichterungen im täglichen Programmieralltag wichtiger als neue Stilmittel zur exakten Validierung beim Kompilieren.

[kimmi]

@Schrompf: Ich denke, das wird durch den jeweiligen persönlichen Kontext bedingt :).

gruß Kimmi

[CodingCat]

Genial: Wenn ich einen Konstruktor / Zuweisungsoperator mittels protected verstecken möchte, muss ich ihn selbst definieren, weil MSVC10 noch kein = default unterstützt. Wenn ich ihn aber selbst als myclass(const myclass&) throw() { } definiere, ist er nicht mehr default, und __has_trivial_copy(myclass) wertet zu false aus.

Da ich mich natürlich wie immer besonders schlau gefühlt habe, war mein nächster Versuch: protected: using myclass::myclass(const myclass&);. Tut das auf keinen Fall, mir sind so viele Compiler-Crash-Message-Boxen um die Ohren geflogen wie noch nie.