Linkdump

[Chromanoid]

Oha. Für wen genau ist das gedacht?

Ich zitiere mal:

This document contains the essential data which is necessary:
™ To assess compatibility of a spacecraft and spacecraft mission with launch
system,
™ To constitute the general launch service provisions and specifications, and
™ To initiate the preparation of all technical and operational documentation
related to a launch of any spacecraft on the launch vehicle.

hab das Ding auch nur beim Browsen auf hackernews gefunden und dachte das weckt hier vielleicht bei dem ein oder anderen Interesse.

[Krishty]

Tut es absolut; danke :)

[Chromanoid]

More dirty coding tricks from game developers http://www.gamasutra.com/view/news/2494 ... lopers.php

[Krishty]

Da steht, das wäre aus dem Game Developer Magazine 2010, aber ich bin mir absolut sicher, das alles schon um 2007 herum auf Gamasutra oder verwandten Seiten gelesen zu haben … komisch. Aber immer wieder guter Lesestoff :)

[mnemonix]

Browser Color Management - Test

Sehr interessant. Ergebnis: Der IE11 und Edge haben perfektes Color Management. Chrome und Firefox haben dagegen ein paar Schwächen. Da stellt sich mir die Frage, wie sieht es da mit Spielen aus? RGB oder sRGB ist da ja meist der Arbeitsfarbraum, aber wie sieht es mit dem Color Management aus, d.h. der Transformation vom Arbeitsfarbraum in den Zielfarbraum des Monitors? Wenige Monitore sind 100%-sRGB konform oder verändern ihre Darstellung über die Zeit hinweg, was mit Color Management und einer Monitor-Kalibrierung/Profilierung kompensiert werden kann. Eine Feststellung habe ich zumindest: Im exklusiven Vollbildmodus eines Spiels geht das Farbmanagement komplett verloren (getestet mit einem Rot-Profil). Da stellt sich mir noch eine Frage: Welcher Quellfarbraum wird standardmäßig angenommen (ich vermute sRGB), normalerweise muss den doch die Anwendung spezifizieren, oder?

[xq]

Falls ihr mal eine Typ2-Sprache parsen müsst und einen guten Parser Generator braucht:
https://github.com/mstoilov/rpatk

Mit dem Toolkit hatte ich bisher die beste Erfahrung, auch wenn man den AST selbst basteln muss (man bekommt ein "Visitor"-Pattern mit Start/Ende von den einzelnen Grammatikteilen)

Dokumentation ist angenehm und hat Beispiele

[mnemonix]

The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++

Nette Sammlung. Leider jedoch noch etwas unvollständig.

[dawit]

The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++

Nette Sammlung. Leider jedoch noch etwas unvollständig.

Darauf aufbauend: der Talk von Herb Sutter, in dem er einen neuen statischen Code Analyzer auf Basis der C++ Core Guidelines vorstellt, der Rust-like Memory Safety zu C++ bringt. Ich weiß nicht, was andere analyse Tools so können, aber das sieht schon verdammt cool aus!

[Krishty]

Wie man vom Brechungsindex einer Materialschicht zum Farbenspiel einer Seifenblase kommt, und zwar die Hardcore-selber-berechnen-Methode: http://wahrheitueberwahrheit.blogspot.c ... -hier.html
Kann man ja für Physically Based Lighting gebrauchen.

[Stift]

Grad brauch ichs zwar nicht, aber auf jeden Fall ein nützlicher Link. Danke.

[Chromanoid]

Wie Künstler des 19. Jahrhunderts die Menschheit im Jahr 2000 sehen, wunderbare Bilder:
http://twistedsifter.com/2015/11/artist ... -year-2000 (via High Scalability)




Hier findet man die Dinger ohne Werbung auf Wikimedia: https://commons.wikimedia.org/wiki/Cate ... _(fiction)

[Jonathan]

Täusch ich mich da, oder wäre das ein sau geiles Szenario für ein Computerspiel? Das ist nicht nur künstlerisch ganz cool, sondern diese Kombination aus alles ist super (weil alles fliegen kann) und alles ist doof (weil diese dünnen FLügelchen bestimmt leicht kaputt gehen und allgemein alles so unrobust aussieht) dürfte auch echt ganz interessante Spielmechaniken ermöglichen.
Bioshock geht möglicherweise etwas in die Richtung, ansonsten fallen mir aber nicht so viele Spiele ein.

[Chromanoid]

@Jonathan: Auf jeden Fall. Insgesamt finde ich von Fluggeräten dominierte Welten immer ziemlich interessant (http://tvtropes.org/pmwiki/pmwiki.php/M ... yIsAnOcean). In Richtung Dieselpunk a'la Porco Rosso oder gar Käpt'n Balu und seine tollkühne Crew ;) fehlt da auch wirklich was schlagendes in der Videospielewelt. Es gibt zwar Spiele wie Air Power (https://www.youtube.com/watch?v=J9IqtzIl30I), Crimson Skies, Guns of Icarus usw. aber so richtig ausgeschöpft scheint mir das Thema noch lange nicht. Aber da sind ja immer wieder Spiele in Entwicklung - zuletzt ist mir Worlds Adrift in Erinnerung geblieben. Du hast aber recht, dass gerade sehr empfindliche Luftkutschen nicht so häufig in Spielen vorkommen.

[Jonathan]

Crimson Skies war sowas von großartig! Ich meine, diese Idee mit den Luftschiffen als 'Flugzeugträger' war nicht nur vom Szenario her großartig, sondern hatte auch einfach wirklich coole Spielmechaniken. Es hat sich einfach irgendwie richtig angefühlt, einzelne Motoren oder Tanks zu zerschießen, oder mitten im Flug an ihnen anzudocken. Und das ergab dann am Ende richtig abwechslungsreiche Missionen, bei denen mal Ballern, mal Kunstflug angesagt war.

Und wo ich mich schon gerade über tolle Spielmechaniken freue: Wolfenstein The new Order scheint mir das erste Spiel zu sein, dass Achievements richtig benutzt. Statt nerviger Abhaklisten mit denen man seine Freunde beeindrucken soll (oder was auch immer?) schaltet man dadurch neue Skills frei. Das ist tatsächlich mal eine vernünftige Belohnung und obendrein eine die viel mehr Spaß macht, als einfach nur Erfahrungspunkte zu sammeln, weil man immer wieder neue, kreative Herausforderungen hat.

[Chromanoid]

Sehr schicke Fraktale:
http://sub.blue/


[via creativeapplications.net via highscalability.com]

[Krishty]

Seine Fabergé-Fraktale sind ja nochmal besser. Schade, dass die Seite so auf mobile Nutzung fixiert ist, dass ich sie am PC kaum ansehen kann.

[Alexander Kornrumpf]

Da auch hier einige undefined behaviour Puristen unterwegs sind wollte ich den Link mal reposten (via fefe):

http://www.complang.tuwien.ac.at/kps201 ... ion_29.pdf

[Krishty]

Fefes Kritik (und die der ganzen „so schlimm kann undefined behaviour nicht gemeint sein, dass man nicht einmal memmove() implementieren kann“-Fraktion) geht IMHO am Problem vorbei. Das Problem ist nicht, dass Programme nach Compiler-Upgrades total kaputtgehen, weil sie irgendwo ein Stückchen Undefined Behaviour nutzen. Das Problem ist, dass C ein totaler Fuckup ist, der viel zu viele Löcher hat und kaum als konsistente Entwicklungsbasis brauchbar ist.

Diese Signed-Right-Shift-Problematik zum Beispiel (kein UB, sondern IB, aber fürs Beispiel ausreichend): C lässt das undefiniert, „damit es auf allen möglichen Architekturen läuft“. Oh, wirklich? Es gibt da draußen Turing-vollständige Architekturen, die unmöglich in der Lage sind, ein Sign Bit zu shiften?! Ins Hirn geschissen?!

Was diese Leute meinen, ist: „damit es auf allen möglichen Architekturen in einen einzigen Maschinenbefehl übersetzbar ist, weil das uns bekannte Universum kollabieren würde, wenn x << 1 ein Funktionsaufruf wäre“. Es geht um Performance, um nichts anderes; und zwar auf feige verdeckte Art und Weise.

Und da sollte man halt lieber eine konsistente Plattform mit recht wenig UB (und stattdessen mehr IB?) zur Verfügung stellen. Die „aber dann muss mein Cray bei x << 1 eine Funktion aufrufen! EMPÖRUNG!!!!“-Idioten können dann auf ihrer Lieblingsplattform genau das tun, was alle Entwickler auf allen Plattformen sowieso schon machen – für native Befehle Intrinsics mit #ifdef drum aufrufen.

Warum nullptr-Defeferenzierungen (hihi) UB sind und nicht IB, für das jede Plattform halt eigenes Verhalten zur Verfügung stellt (GCC löscht den Ausführungspfad; Win32 löst eine SEH aus; die 0,001 % Gerätetreiber, bei denen 0 tatsächlich als Adresse gemappt ist, verhalten sich dementsprechend), werde ich wohl nie kapieren.

[Alexander Kornrumpf]

Man kann es "am Problem vorbei" nennen, man kann es aber auch Schadensbegrenzung ob der Tatsache, dass das uns bekannte Universum nunmal in C geschrieben ist nennen.

[Krishty]

C ist nicht unabänderlich. In der letzten C-Revision haben sie die Signed Division-Problematik gelindert (nachdem das eh jede Architektur so gemacht hat). Sie könnten Signed Shifts definieren, nachdem sich eh jede Architektur für Arithmetic Shift entschieden hat.

Wäre viel effektivere Schadensbegrenzung, dafür fehlt aber einfach das Bewusstsein und so wird der Bote erschossen (der optimierende Compiler).

[Alexander Kornrumpf]

C ist nicht unabänderlich. In der letzten C-Revision haben sie die Signed Division-Problematik gelindert (nachdem das eh jede Architektur so gemacht hat). Sie könnten Signed Shifts definieren, nachdem sich eh jede Architektur für Arithmetic Shift entschieden hat.

Wäre viel effektivere Schadensbegrenzung, dafür fehlt aber einfach das Bewusstsein und so wird der Bote erschossen (der optimierende Compiler).

Verstehe ich das Problem falsch? Es gibt einen Konflikt zwischen Leuten, die Compilercode schreiben, und Leuten, die existierendem Code warten. Der Standard ist bezüglich dieses Konfliktes agnostisch in dem Sinne das er weder verbietet was die eine Partei lieber hätte noch was die andere Partei lieber hätte. Jetzt sagst du das eigentliche Problem ist dass der Standard es nicht regelt obwohl sich eh alle einig sind?

[Krishty]

„Einig“ sicher nicht, aber der Konflikt – „Wie gehen wir mit Undefiniertem Verhalten um?“ – wäre nicht so groß, wenn der C-Standard Undefiniertes Verhalten minimieren würde.

Das passiert nicht; mit der Argumentation, UB würde C kompatibel zu allen möglichen Architekturen halten. Tatsächlich ist aber keine Zeile mehr portabel oder überaupt noch kompatbiel (siehe memove()).

Ich denke, dass C da nicht agnostisch ist, sondern den Compiler-Leuten (die ja in den 70ern gern jeden Ausdruck direkt in einen Assembler-Befehl übersetzen wollten, und für die UB Arbeitsersparnis bedeutet) viel zu sehr entgegenkam. Das ist aber nicht Verfehlung der Compiler-Leute, sondern des Standardisierungskomitees.

[Alexander Kornrumpf]

Das ist aber nicht Verfehlung der Compiler-Leute, sondern des Standardisierungskomitees.

Ich kann nicht beurteilen wer hier einen Fehler macht. Ich habe die Einstellung, die durch diesen infantilen "Festplatte formatieren"-Witz (ich hoffe es ist ein Witz?) symboliert wird ein paarmal in freier Wildbahn getroffen (ohne selbst C-Entwickler zu sein) und ich finde diese Einstellung extrem unpragmatisch. Von daher wollte ich einfach mal die Gegenmeinung weiter vebreiten. Um über Ursachen und Lösungen zu spekulieren kenne ich das C-Ökosystem zu wenig.

Insbesondere, ich weiß nicht wie einig wir uns da sind, verdient hypothetischer ein Compilerentwickler, der wirklich (mehr oder weniger mit Absicht, und nicht durch einen Zufall von Douglas Adamschen ausmaßen) die Festplatte formatiert, weil er es laut Standard "darf", meiner Meinung nach beliebig schlechtes Karma. No way wäre das in meinem Weltbild eine Verfehlung von jemand anderem als diesem Entwickler selbst.

Was mich erschreckt, ist dass einige offenbar intelligente Menschen näherungsweise der Meinung sind, das mit dem Formatieren wäre wirklich ok. Womit ich meine erste Frage selbst beantwortet habe.

[Krishty]

Wow, sowas wird wirklich gemacht? Das Schlimmste, das ich bisher getroffen habe, war einfach ein Absturz oder eine Endlosschleife.

Wer hat das denn gemacht?

[Alexander Kornrumpf]

Nicht gemacht (soviel ich weiß). Leuten als "Argument" um die Ohren gehauen, wenn sie es wagen boundschecks zu machen. In der Sprache unserer Zeit: eine Verrohnung des Diskurses.

Was ist das für eine Art einen Dialog zu führen?

- "Ich will Boundschecks machen können"
- "Sei froh dass ich deine Festplatte nicht formatiere, du Wicht"

[Krishty]

Hehe. Microsoft sind da die pragmatischsten. Die sagen: Der Adressraum ist unter Win32 flach und alles ist adressierbar. Da sind Boundchecks dann kein UB mehr (auch wenn man sich trotzdem anstrengen muss, dass sie nicht wegoptimiert werden). Dafür ist ihr Compiler dann nicht standardkonform (sie haben unser heiliges UB zu IB gemacht) und alle spucken drauf.

[Spiele Programmierer]

@Krishty
Der Compiler ist deswegen nicht standardkonform?
Undefined Behaviour heißt doch, dass vom Standard her undefiniert ist, was passiert. Das schließt aber doch nicht aus, dass auf einer bestimmten Plattform in einer Situation immer das selbe Verhalten eintritt.

@Alexander Kornrumpf
Der Kern des Problems mit Undefined Behavour ist nicht, dass irgendein Compiler dann Code einsetzt, der anfängt die Festplatte zu formatieren oder sowas. Die Aussage steht nur stellvertretend dafür, dass tatsächlich undefiniert ist was dann passiert und mit entsprechender Wahrscheinlichkeit wirklich alles passieren kann. Die Sache mit der Formatierung ist normalerweise natürlich ausreichend unwahrscheinlich. Man denke doch aber mal an den Quellcode von dem Programm "format", das dafür geschrieben wurde die Festplatte zu formatieren. Mit Undefined Behaviour wäre es realistisch denkbar, dass die Ausführung vom Programmierer unbeabsichtigt von irgendeiner Stelle irgendwie in die Formatierungsroutine springen kann.

Im Prinzip ist auftretender Undefined Behaviour einfach ein Bug. Genau wie bei einem Bug wird Verhalten ausgelöst das vom Programmierer mehr oder weniger nicht erwünscht ist. Auftretender Undefined Behaviour ist also per Definition "böse". Bounds Checks sind an sich kein Problem. Ein Problem wäre aber, wenn der Bounds Check zu Undefined Behaviour führt, der zum Beispiel dafür sorgt, dass der Compiler (oder ein anderer) den Bounds Check komplett wegoptimiert so das gar nicht mehr gecheckt wird. (das hat schon ganz konkret in der Praxis für Probleme gesorgt)

Um dem Problem vorzubeugen eignet, bietet zum Beispiel Clang Sanitizer an, um das Problem aufspühren zu können (Undefined Behavior, Address, etc.). Sehr lesenswert ist auch noch das: What Every C Programmer Should Know About Undefined Behavior

Ich bin prinzipiell aber auch dafür, dass man die Menge an Undefined Behaviour drastisch einschränkt. Kristhy hat schon einige Stellen von leicht zu behebenden Fällen genannt. Andere Fälle wie zum Beispiel Integer Overflow könnt man von Undefined Behaviour zu Unspecified Value umwandeln. Ich glaube nicht, dass dadurch viele nützliche Optimierungen betroffen wären.

[Alexander Kornrumpf]

@Alexander Kornrumpf
Der Kern des Problems mit Undefined Behavour ist nicht,

Ich weiß was undefined behaviour ist, danke.

dass irgendein Compiler dann Code einsetzt, der anfängt die Festplatte zu formatieren oder sowas. Die Aussage steht nur stellvertretend dafür, dass tatsächlich undefiniert ist was dann passiert und mit entsprechender Wahrscheinlichkeit wirklich alles passieren kann. Die Sache mit der Formatierung ist normalerweise natürlich ausreichend unwahrscheinlich. Man denke doch aber mal an den Quellcode von dem Programm "format", das dafür geschrieben wurde die Festplatte zu formatieren. Mit Undefined Behaviour wäre es realistisch denkbar, dass die Ausführung vom Programmierer unbeabsichtigt von irgendeiner Stelle irgendwie in die Formatierungsroutine springen kann.

Mein Punkt war, dass es entlarvend ist, wie das mit dem Formatieren als Totschlagargument gebraucht wird.

Im Prinzip ist auftretender Undefined Behaviour einfach ein Bug. Genau wie bei einem Bug wird Verhalten ausgelöst das vom Programmierer mehr oder weniger nicht erwünscht ist. Auftretender Undefined Behaviour ist also per Definition "böse". Bounds Checks sind an sich kein Problem. Ein Problem wäre aber, wenn der Bounds Check zu Undefined Behaviour führt, der zum Beispiel dafür sorgt, dass der Compiler (oder ein anderer) den Bounds Check komplett wegoptimiert so das gar nicht mehr gecheckt wird. (das hat schon ganz konkret in der Praxis für Probleme gesorgt)

Dass Compiler z. B. Boundchecks als undefined behaviour wegoptimieren ist weder ein Naturgesetz noch eine Vorgabe des Standards sondern schlicht eine Entscheidung der Compilerentwickler. Es ist diese Entscheidung, die kritisiert wird.

[Alexander Kornrumpf]

Noch eine Ergänzung: Ich habe den Eindruck, dass es wirklich Leute gibt, die glauben, dass es ihnen der Standard erlaubt, und zwar nicht im Sinne von Standardkonformität, sondern moralisch wie rechtlich wirklich _erlaubt_, für ub beliebigen Code einzusetzen, und dass es ein reiner Akt der Nächstenliebe ist, dass sie nur nop einsetzen und nicht irgendwas wirklich schädliches. Und vielleicht ist das etwas übertrieben, und vielleicht glaubt niemand das komplett, sondern, wie ich oben sagte, nur näherungsweise, in mehr oder weniger hitzigen Diskussionen, aber ich halte das für ein extrem gefährliches Weltbild.

[Spiele Programmierer]

Ich denke, da geht es viel mehr ums Prinzip. Und in heftigen Diskussionen bei besonders kritikressistenten Programmier ("Ich will die Bounds Checks aber mit UB! Und bei mir funktioniert es ja!") kann ich mir schon vorstellen, dass der Eindruck erweckt wird, man würde sich wünschen, die Compiler würden es demjenigen "heimzahlen".

Sicherlich fände keiner gut, wenn Compiler die Festplatte aus Jux formatieren. Aber es ist halt Tatsache, dass viele gänige Compiler die Möglichkeit zur Optimierung nutzen bzw. nutzen möchten und werden. Auch wenn man das doof findet, ist es schlicht und ergreifend trotzdem eine sehr schlechte Idee die Bounds Checks so zu schreiben, dass sie bei einigen Compilern wegoptimiert werden. Oder vielleicht beim nächsten Update. Und dann muss man die Programmierer darauf hinweisen und ihm muss klar werden, dass er die Bounds Checks so nicht schreiben darf. Auch nicht wenn sie gerade auf den Compiler zu funktionieren zu scheinen. Es sind eben durchaus auch sehr viel unglücklichere Situationen denkbar! Die Sache mit der Formatierung der Festplatte ist zwar nicht sehr realistisch und etwas überspitzt, soll das aber eigentlich auf den Punkt bringen.