Anti-Jammer-Thread

[Krishty]

Mein Font-Renderer hat Leerzeichen zum Zeichnen geschickt. Schön, dass ich nach so vielen Monaten immernoch kleine Verbesserungsmöglichkeiten finde.

[Krishty]

Ich überlge, in meiner CRT bestimmte globale Variablen in eigenen Threads zu initialisieren. Anstatt dass so seriell Dateien geöffnet, Registry gelesen, und GPU-Kontext angefordert wird, geschähe das zumindest auf Makroebene parallel. Die entsprechenden Variablen wären speziell markiert.

Ich frage mich, inwieweit das überhaupt was bringen würde. Weil Windows außer dem GPU-Kontext alles cachet, ist der wahrscheinlich die eine einzige langsame Sache auf die letztendlich alles andere warten würde. Außerdem würde es RAII an sich in Frage stellen.

Sooo. Ich habe heute einen Prototypen hingehackt und ins nächste Projekt kommt das definitiv rein – dann werden Renderer, Dateisystem, Eingabesystem, und Klangausgabe nebenläufig initialisiert. Und alles, was ich sonst noch so finde. Mit RAII ist nichts kollidiert; es sind „normale“ globale Variablen und für den Rest des Programms sieht ihre Lebenszeit normal aus.

Ich hasse es, wenn Programme nicht sofort auf dem Bildschirm erscheinen.

[Schrompf]

Ja, da bin ich mit Dir. Schön, dass es so einfach ging!

[Krishty]

Als ich heute morgen meinen PC aus dem Stand-By geweckt habe, war mein Spiel automatisch pausiert. So Malheurs wie, dass mittendrin der Bildschirmschoner anspringt (weil Windows dafür nur Tastatur- und Mauseingaben kontrolliert; aber nicht Joysticks und Lenkräder), habe ich ebenfalls ausgeschlossen.

Vielleicht poste ich dieses Wochenende eine kurze Zusammenfassung der ganzen Energieverwaltung; ich weiß nur nicht, ob sich mit Windows RT und dem ganzen Windows 8-Kram irgendwas zu stark geändert hat …

[CodingCat]

C++14 Best Of

Abgenickt:

• Variable templates ala "template <typename T> int foo<T> = ..."
• Run-time sized arrays on the stack got in as well. Very mild controversy there, but in the end it was pretty much unanimous.
• Third controversial issue, std::dynarray, got voted in as well.

Zur Debatte?

• "auto f(int i) { if (i < 1) return 1; else return f(i-1) * i; }" will likely be valid C++14
• C++14 will also likely include binary literals like 0b101010. Maybe we should call it C++0b1110?

Nebenbei ist clang soeben C++11-complete geworden. Das entsprechende Release wird im Sommer erwartet.

[Krishty]

C++14

Run-time sized arrays on the stack got in as well.

[Artificial Mind]

Ich habe jetzt meinen eigenen funktionierenden C++11-kompatiblen Preprozessor fertig geschrieben. Berechnet auch direkt die Byterepräsentationen aller ppNumber- und String/Char-Literale (auch user defined strings/chars).

Auf meinem Weg zum eigenen C++11-Kompiler steht also wahrscheinlich als nächstes die C++-Syntax-Analyse an. Ich freu mich schon :)

[Helmut]

Run-time sized arrays on the stack got in as well.

Pff, ich seh's schon kommen. Leute werden Benutzereingaben ohne Längenbegrenzung so auf dem Stack speichern und sich dann über DoS Attacken wundern. Vielleicht sogar Sicherheitslücken, wenn das Programm irgendwie versucht Stack Overflow Exceptions zu recovern.

[Schrompf]

Bin nicht ganz sicher, ob das Material für den Jammer-Thread oder für Anti-Jammer ist. Ich habe gerade einen Bug im Splatter-Lichtshader gefixt, bei dem die fiktive Höhe eines Pixels nur für die Schattenberechnung, aber nicht für Attenuation und die Spotlight Cone verwendet wurde. Der Fix hat das komplette Erscheinungsbild des Spiels subtil verändert. Manche Dinge sehen jetzt einfach nur "richtig" aus, andere dagegen sehen jetzt aus wie reinkopiert.

Leider ist die Erstellung ordentlicher Relief Maps zu allen Grafiken eine ziemlich mühsame Arbeit, die sich mein Grafiker größtenteils erspart hat. Bisher hat man das nur an den bisweilen seltsamen Schatten-Silhouetten gesehen, die bei uns ja eh relativ weichgezeichnet erscheinen. Jetzt sieht man es aber auch im Licht jedes Scheinwerfers, dass die Höhen nur wie in einem billigen NormalMap-Generator aus der Farbtextur abgeleitet wurden.

Nuja, ich muss eh vor Release nochmal über alle Grafiken drüber. Das ist dann nur ein weiterer Posten auf der ewig wachsenden Liste.

[Edit] Damit das noch etwas anti-jammeriger klingt: Das letzte Level ist fertig, inklusive Musikdynamik, Speicherpunkten und allen Dialogen und Verzweigungen. Es ist noch nicht sonderlich hübsch, weil es noch vom Grafiker aufpoliert wird, aber es funktioniert und hat ein paar coole Szenen. Und inzwischen habe ich auch ein grobes Konzept für den Bosskampf entwickelt und bastle gerade fröhlich an der ersten Phase des Kampfes.

[kimmi]

Innerhalb einer Woche das neue Haus gestrichen und teil-tapeziert, umgezogen, die alte Wohnung renovieren lassen und über die Hälfte aller Kisten verstaut. Und nun wieder arbeiten. Sprich: ich sehe gerade mal keine neue Kiste :).

Guß Kimmi

[Krishty]

Visual C++ erkennt mit /fp:precise, dass sich -x + y zu y - x optimieren lässt. Das ist … überraschend und beruhigend. Ich hatte die Hoffnung längst aufgegeben …

[Aramis]

Irgendjemand hat Videos von den ersten 8 Levels von Entropy auf Youtube gepostet (in der Xbox-Fassung, mit entsprechender Qualitaet). Irgendwie komisch das zu sehen, aber durchaus spassig :-)

Ich glaube, danach hat er aufgegeben.

[youtube]7JEOv5lanmM[/youtube]

[Chromanoid]

Hehe, zumindest ich hab mich da wieder gefunden. :D

[Schrompf]

Großartig!

[kimmi]

Wie wahr :) ...

[antisteo]

Haben wir schon Weihnachten?

http://www.heise.de/newsticker/meldung/ ... 57164.html

[Krishty]

Haben Mobilcomputer also endlich die Größe, Komplexität, und Software-Qualität erreicht, dass sich RISC nicht mehr lohnt? Arme Welt.

OKOK; damit alle verstehen, worum es geht:

ARM hat afaik (Besserwisser erwünscht) RISC-Maschinen produziert; also Maschinen, deren Befehlssatz im Gegensatz zu Desktop-CPUs klein war. Ganz plattes Beispiel: Während eine Desktop-CPU Operationen für Addition, Negierung, und Subtraktion hat, hat eine RISC-CPU nur Operationen für Addition und Negierung, weil sich die Subtraktion durch Addition und Negierung emulieren lässt.

Will man eine CPU schneller machen, kann man am einfachsten den Takt erhöhen. Das ist aber langfristig eine Sackgasse (wir erinnern uns ja alle noch an die frühen 2000er, als sie den Pentium-4-Kern gegen 7 GHz getaktet haben, und es dann doch lieber sein gelassen haben): Taktet man die CPU doppelt so hoch, zieht sie vier Mal so viel Strom. Wir sehen, dass man da mit Verbrauch und Wärmeentwicklung gegen eine Wand rennt.

Darum sind in den letzten Jahren die CPUs nicht mehr schneller, sondern größer geworden: Verbaut man zwei Kerne statt einem, hat man theoretisch die doppelte Leistung, aber auch nur den doppelten Verbrauch (gegenüber dem Vierfachen eines doppelten Takts). Verbaut man eine zusätzliche Befehle in die CPU, wird die zwar größer, aber schafft mehr pro Takt (im Beispiel oben eine Subtraktion in einem Takt statt in zwei für Negierung und Addition). Wir wissen ja alle, wie viel schneller man Mathe durch SSE kriegt, weil die CPU dann breiter operiert als auf Skalaren. Da habe ich auch nichts gegen; so weit, so gut.

Aber auch damit kam man irgendwann nicht weiter: Darum baut man so Sachen ein wie Sprungvorhersage, Out-of-Order-Ausführung, schnelle Zugriffe auf nicht ausgerichtete Speicherbereiche, µOp-Cache, und den ganzen anderen Kram. Das Besondere an diesen Optimierungen ist, dass sie die Verfehlungen des Maschinentextes glätten indem sie den Kram auseinandernehmen und optimiert wieder zusammenstecken, bevor die CPU sie ausführt. Das ist bei Desktop-CPUs seit Jahren die Hauptmethode, um noch Leistung zu gewinnen.

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben. Auf Desktop-CPUs spielt das keine Rolle, weil die Software eh Schrott ist und die CPUs sowieso zig hundert Watten saugen und nur Leistung, Leistung, und nochmal Leistung bringen sollen. Aber wenn man jetzt bei Mobilarchitekturen, mit durchdachten statt gewucherten Befehlssätzen, Transistoren dafür raushaut, dann finde ich das bedenklich. Und wenn man damit auch noch gewaltig Leistung gewinnt, ist das meiner Meinung nach nur ein Armutszeugnis für die Software- und Compiler-Qualität der ganzen Branche (denn ein Programm, das für die Ziel-Pipeline optimiert wäre, würde durch OoOE überhaupt nicht schneller). Aber vielleicht habe ich auch einfach nichts aus Itanium gelernt.

[Alexander Kornrumpf]

Also fefe, falls du es nicht gelesen haben solltest und ich es richtig verstanden habe, hat das so interpretiert, dass die Intel Desktop CPUs in Zukunft weniger Strom ziehen werden.

Das was du hier bemägelst scheint er als Naturkonstante einfach angenommen zu haben (a la "gelohnt" hat sich ARM nie, es hat nur wenig Strom gezogen).

Du vergleichst eine Welt in der die Leute auf ARM optimiert haben weil der Prozessor langsam war mit einer in der man das nicht mehr "muss".

Fefe vergleicht eine Welt in der die Software langsam lief weil der Prozessor langsam war mit einer in der sie schnell(er) läuft.

Wie gesagt, falls ich das nicht missverstehe...

[Lynxeye]

[...]
Aber auch damit kam man irgendwann nicht weiter: Darum baut man so Sachen ein wie Sprungvorhersage, Out-of-Order-Ausführung, schnelle Zugriffe auf nicht ausgerichtete Speicherbereiche, µOp-Cache, und den ganzen anderen Kram. Das Besondere an diesen Optimierungen ist, dass sie die Verfehlungen des Maschinentextes glätten indem sie den Kram auseinandernehmen und optimiert wieder zusammenstecken, bevor die CPU sie ausführt. Das ist bei Desktop-CPUs seit Jahren die Hauptmethode, um noch Leistung zu gewinnen.

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben. [...]

Hier bist du leicht unfair.
Ja, Compiler sind immer noch meilenweit hinter dem Zustand in dem man sie sich wünschen würde, allerdings sind viele der Dinge welche OoO Execution & Co gerade biegen nicht nur Compilerverfehlungen. Ich jedenfalls möchte nicht jedes Programm für genau die Pipeline eines Prozessors compilieren müssen. Auf den ARMs ist es schon ein genügend großer Aufwand für jede Inkarnation des Befehlssatzes neue Binaries zu bauen, ich möchte nicht noch für jeden Implementer des Befehlssatzes ein eigenes Binary haben. Da hätte ich also gern OoO um ein klein wenig flexibler zu sein.

Harwarebeschleunigte unaligned Loads/Stores haben auch ihre Berechtigung. Sieh dir die ganzen neuen superschnellen Komprimierungsalgorithmen wir snappy und LZ4 an, welche an der Schallmauer der RAM-Geschwindigkeit kratzen. Ohne unaligned Load/Store wäre der Text in den innersten Schleifen viel größer und die Performance würde extrem einbrechen.

µOP Cache sind auch allgemein hilfreich, die Dekoder sind, unabhängig ob nun ARM oder x86, einer der größten Energieschlucker der CPU. Wenn ich diese für die Laufzeit einer Schleife abschalten kann, weil alles noch im Tracebuffer liegt, gewinne ich beim Stromverbrauch einiges.

[kaiserludi]

welche an der Schallmauer der RAM-Geschwindigkeit kratzen..

Da fällt mir doch glatt auf: Dem Forum fehlt eindeutig ein Thread, in dem die schönsten Formulierungen des Forums gesammelt werden :D

[Krishty]

Also fefe, falls du es nicht gelesen haben solltest und ich es richtig verstanden habe, hat das so interpretiert, dass die Intel Desktop CPUs in Zukunft weniger Strom ziehen werden.

Desktops werden aber hoffentlich nicht mit den dort vorgestellen Tablet-CPUs arbeiten! Außerdem sprach ich mit antisteo statt fefe.

Du vergleichst eine Welt in der die Leute auf ARM optimiert haben weil der Prozessor langsam war mit einer in der man das nicht mehr "muss".

Fefe vergleicht eine Welt in der die Software langsam lief weil der Prozessor langsam war mit einer in der sie schnell(er) läuft.

Schneller und sparsamer werden die CPUs aber schon allein durch neue Fertigungstechnologien. Das meiste, was Intel da vorgestellt hat, ist jedenfalls nicht dem Stromverbrauch zuträglich sondern nur dazu da, sich möglichst schnell in diesem Bereich breitzumachen indem man erträglich schnelles x86 anbietet (wie schon damals bei den Netbooks) und damit den Programmierern eine Last abnimmt (und sie so noch schlechtere, ältere, und – vor allem – billigere Software anbieten lässt).

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben.

Hier bist du leicht unfair.
Ja, Compiler sind immer noch meilenweit hinter dem Zustand in dem man sie sich wünschen würde, allerdings sind viele der Dinge welche OoO Execution & Co gerade biegen nicht nur Compilerverfehlungen. Ich jedenfalls möchte nicht jedes Programm für genau die Pipeline eines Prozessors compilieren müssen. Auf den ARMs ist es schon ein genügend großer Aufwand für jede Inkarnation des Befehlssatzes neue Binaries zu bauen, ich möchte nicht noch für jeden Implementer des Befehlssatzes ein eigenes Binary haben. Da hätte ich also gern OoO um ein klein wenig flexibler zu sein.

Du möchtest also statische Arbeit, die theoretisch Compiler und Entwickler übernehmen könnten (nämlich das Optimieren auf eine bestimmte Architektur) zur Ausführungszeit durch zusätzliche Transistoren erledigen lassen. Ja gut; das ist eine legitime Meinung (obwohl ich sie nicht teile); nur hat das nicht viel mit Energieeffizienz zu tun und ich möchte das deshalb nicht in meinem Tablet.

Harwarebeschleunigte unaligned Loads/Stores haben auch ihre Berechtigung. Sieh dir die ganzen neuen superschnellen Komprimierungsalgorithmen wir snappy und LZ4 an, welche an der Schallmauer der RAM-Geschwindigkeit kratzen. Ohne unaligned Load/Store wäre der Text in den innersten Schleifen viel größer und die Performance würde extrem einbrechen.

Wie meinen? Wenn der RAM limitiert, ist doch die Menge des Maschinentextes, der drauf wartet, egal? Und nochmal: Damit verbraucht jedes Laden und Speichern, das jemals von irgendeinem Programm durchgeführt wird, vier- bis fünfmal so viel Strom, damit deine einzelne innere Schleife es nicht explizit hinschreiben muss. In meinem Telefon finde ich das nicht wirklich berechtigt.

µOP Cache sind auch allgemein hilfreich, die Dekoder sind, unabhängig ob nun ARM oder x86, einer der größten Energieschlucker der CPU. Wenn ich diese für die Laufzeit einer Schleife abschalten kann, weil alles noch im Tracebuffer liegt, gewinne ich beim Stromverbrauch einiges.

Wäre das Kompilat für die Zielarchitektur kompiliert, entfiele die Übersetzung in µOps komplett und der einzige Stromfresser wäre der Cache. Siehe Itanium, der den Maschinentext direkt an die Recheneinheiten durchgereicht hat.

Der war natürlich eine große Katastrophe; aber der Tablet-Markt ist (zum Glück!) kein Markt, wo man jedes Jahr eine neue CPU einbaut und alle drei Jahre ein neues OS, und sich seine Programme jedes Mal rüberkopiert. Meistens kann man sich die Programme für Pad und Telefon ja nicht einmal ab Werk frei aussuchen und die Hardware-Variation ist Kerneigenschaft statt Exot.

Jedenfalls glaube ich nach allem, was ich bisher von x86 gesehen habe, dass langfristig niemand davon profitiert, dass Telefone nun OoO laufen.

[Schrompf]

Nikis Freude über logarithmische Tiefen und die daraus entstehende Diskussion abgetrennt nach http://zfx.info/viewtopic.php?f=5&t=3025

[Krishty]

Boooooooooaaaaaaah

Vier Jahre lang habe ich Assembly analysiert; habe meine Programme Byte für Byte optimiert

vier lange Jahre

und nachdem mein ganzes Projekt nur noch zwei virtuelle Funktionen beinhaltet, sitze ich nun zum ersten Mal in meinem Leben vor einem Fall, in dem Visual C++ eine virtuelle Funktion geinlinet hat!

Durch einen variablen Zeiger, wo der Optimizer erstmal raffen muss, worauf der verweist!

Und durch drei andere Mini-Funktionen durch auch noch!

Visual C++ kann es!

Ich vermute ganz schlicht, dass das Feature nie zuende getestet wurde, und jetzt, wo ich nur noch eine vtable-lose Basisklasse mit einer einzigen virtuellen Funktion und einer einzigen Implementierung habe, funktioniert es endlich wie gewollt!

Kandidat:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &	stream,
	UTF16Unit const *	toZeroTerminatedString
) {
	while(L'\0' != *toZeroTerminatedString) {
		auto const output = (128u > *toZeroTerminatedString) ? ASCIICharacter(*toZeroTerminatedString) : ASCIICharacter('?');
		stream << output;
		++toZeroTerminatedString;
	}
	return stream;
}

stream << output; ruft auf:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &		stream,
	ASCIICharacter const	ASCIICharacter
) {
	stream.append(range(&ASCIICharacter, &ASCIICharacter + 1));
	return stream;
}

stream.append() ist implementiert als:

Code: Alles auswählen

void ASCIIStreamWriter::append(
	Range<ASCIICharacter const> const & output
) {
	assert("invalid output stream bound", nullptr != myToStream);
	return myToStream->append(range(
		reinterpret_cast<Byte const *>(output.toBeginning),
		reinterpret_cast<Byte const *>(output.toEnd)
	));
}

myToStream verweist auf

Code: Alles auswählen

class __declspec(novtable) OutputStream {
public:

	virtual void append(
		Range<Byte const> const &
	) = 0;

};

Die einzige Implementierung der Funktion ist:

Code: Alles auswählen

	void StandardOutputStream::append(
		Range<Byte const> const & output
	) {
		assert("invalid std stream", WinAPI::invalidHandleValue != myHandle);
		assert("std output too long", 0x7FFFFFFF >= sizeOf(output));
		assert("invalid std output", nullptr != output.toBeginning);

		// See http://msdn.microsoft.com/en-us/library/aa365747.
		UnsignedInt4B writtenSize = 0;
		WriteFile(myHandle, toBeginningOf(output), UnsignedInt4B(sizeOf(output)), &writtenSize, nullptr);

		return;
	}

Der entstandene Maschinentext:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &	stream,
	UTF16Unit const *	toZeroTerminatedString
) {
 push        rbx  
 push        rbp  
 push        rdi  
 sub         rsp,30h  
	while(L'\0' != *toZeroTerminatedString) {
 movzx       eax,word ptr [rdx]  
 xor         ebp,ebp  
 mov         rbx,rdx  
 mov         rdi,rcx  
 cmp         bp,ax  
 je          operator<<+7Fh (0140006C0Fh)  
 mov         qword ptr [rsp+60h],rsi  
		stream << output;
 lea         rcx,[stream]  
 lea         rsi,[rsp+51h]  
 mov         qword ptr [rsp+68h],r14  
 mov         r14d,80h  
 sub         esi,ecx  
		auto const output = (128u > *toZeroTerminatedString) ? ASCIICharacter(*toZeroTerminatedString) : ASCIICharacter('?');
 cmp         r14w,ax  
 jbe         operator<<+3Fh (0140006BCFh)  
 movzx       eax,byte ptr [rbx]  
 jmp         operator<<+41h (0140006BD1h)  
 mov         al,3Fh  
		stream << output;
 mov         rcx,qword ptr [rdi]  
 mov         byte ptr [stream],al  
 lea         r9,[toZeroTerminatedString]  
 mov         rcx,qword ptr [rcx+8]  
 lea         rdx,[stream]  
		stream << output;
 mov         r8d,esi  
 mov         dword ptr [toZeroTerminatedString],ebp  
 mov         qword ptr [rsp+20h],rbp  
 call        qword ptr [__imp_WriteFile (01400250D0h)]  
	while(L'\0' != *toZeroTerminatedString) {
 movzx       eax,word ptr [rbx+2]  
		++toZeroTerminatedString;
 add         rbx,2  
 cmp         bp,ax  
 jne         operator<<+34h (0140006BC4h)  
 mov         r14,qword ptr [rsp+68h]  
 mov         rsi,qword ptr [rsp+60h]  
	}
	return stream;
 mov         rax,rdi  
}
 add         rsp,30h  
 pop         rdi  
 pop         rbp  
 pop         rbx  
 ret  

call qword ptr [__imp_WriteFile (01400250D0h)]!!!!

Selbst, wenn ich das __declspec(novtable) wegnehme, klappt es! Da dann zwei Kandidaten für den Aufruf bleiben (der Stub für die pur virtuelle Funktion und die tatsächliche Implementierung), bedeutet das, dass der Optimizer tatsächlich den Typ hinter dem Zeiger gerafft hat. Ich bin baff. Vielleicht ist Visual C++ autistisch? Kann sich nicht selber anziehen, aber Muster in Telefonnummern finden?

[Krishty]

und nachdem mein ganzes Projekt nur noch zwei virtuelle Funktionen beinhaltet, sitze ich nun zum ersten Mal in meinem Leben vor einem Fall, in dem Visual C++ eine virtuelle Funktion geinlinet hat!

Man kann das Ganze jetzt noch ad absurdum führen:

Ich habe gemerkt, dass die Funktion immer geinlinet wird.

Der Compiler legt aber grundsätzlich eine nicht-inline-Kopie jeder virtuellen Funktion an, damit an der richtigen Stelle der Virtual Function Table jeder Instanz ein gültiger Zeiger steht. Diese Kopie der Funktion wird niemals aufgerufen, weil die Funktion, wie gesagt, immer geinlinet wurde.

Ich kann nun via __declspec(novtable) erzwingen, dass für die Klasse kein Virtual Function Table angelegt wird. Benutzt wird er sowieso nie, weil die einzige virtuelle Funktion überall geinlinet wurde. Da die vtable die einzige Referenz der nicht geinlineten Funktion war, entfällt die Funktion komplett. Das hört sich popelig an, macht aber selbst bei einem Einzeiler locker 400 Bytes Maschinentext aus.

Ich habe jetzt also eine Klasse, die eine Schnittstelle implementiert ohne dabei ihre Methoden virtuell aufrufen zu lassen; und die nur so lange nicht abstürzt, wie ihre Methoden geinlinet werden. lol

Ich frage mich langsam wirklich, was die sich bei alledem gedacht haben. LTCG könnte locker statisch bestimmen, wann eine vtable nicht referenziert wird, und alle Funktionen selber entfernen. MFC-Projekte würden auf die Hälfte zusammenschrumpfen. Bei gutem Programmentwurf sollte die Situation, in der Visual C++ jetzt steckt (dass man jede vtable opt-outen muss und die ganze Exe voll nicht referenzierter Funktionen ist), überhaupt niemals auftreten. Lächerlich, das alles.

[Chromanoid]

GungHo made $118m in April alone, market cap exceeds Nintendo
Der Spielemarkt ist ein riesengroßes Kasino. Wir sind die Automatenspieler der Spieleindustrie.

Könnte auch in den Jammer-Thread, aber irgendwie zeigt es auch wunderbar warum Spieleentwicklung nicht nur aus unterhaltungskünstlerischer Hinsicht so faszinierend ist.

[CodingCat]

C++14 Draft ist da.

[Schrompf]

Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.

[CodingCat]

Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.

Dann empfehle ich die ISO C++ Sprint Meeting Trip Reports von Herb Sutter und Michael Wong (1, 2, 3).

[Krishty]

Wow; Turnitin.com indiziert ZFX.

Vielleicht sollten wir uns langsam überlegen, unter welcher Lizenz der Inhalt dieser Seite zur Verfügung gestellt wird – was ich hier schreibe, veröffentliche ich grundsätzlich gemeinfrei und sporne Kopien an. Also nicht, dass mal jemand auf den Deckel bekommt, weil er Quelltext aus meinen Jammer-Beiträgen kopiert hat …

[TDK]

Ich bin so stolz auf mich, was mein neuer Speichermanager alles ermöglicht.

Anstatt mir dauernd temporäre Dateien anlegen zu lassen, um wegwerf-Müll zwischenzuspeichern, habe ich mir nun eine Klasse memory_file entwickelt, die das alles auch im RAM regeln kann. Das System ist sogar so erweitert, dass ich auch gleich eine Datei von der Platte lesen kann bzw. speichern kann. Endlich habe ich eine Klasse für alles! Danke Gott, der mir Hirn verschafft hat.