Jammer-Thread

[Alexander Kornrumpf]

Ich hatte sogar noch gerade gelesen, dass es der niedrigpriorste Operator ist aber dann nicht richtig was aus der Information gemacht.

Nur fürs Protokoll: Streich das oben und ersetze durch

a=b;
c;
d;

vs.

a=b,c,d;

EDIT:
Wir müssen mit dem Cross-Editing aufhören. Dass es darum geht einen Sequence-Point zu setzen ist ja die Lehrbucherklärung für den Operator. Selbst wozu man das wollen könnte (um eine Sequenz festzulegen, stupid) ist manchmal noch erklärt. Aber ich vermute mal das ein ; auch einen Sequenzpunkt setzt (ganz dünnes Eis, sorry. Jedenfalls tut es sowas ähnliches wie , was die Programmreihenfolge betrifft) und mir ist nie so richtig klar geworden wo man das was , weniger / anders tut als ; auch genauso brauchen würde.

[Schrompf]

Ich bin gescheitert, Nicht-Programmierern die Benutzung einer Versionsverwaltung beizubringen. Nicht nur, dass es nicht ganz einfach ist, bei einem großen Projekt zu wissen, welche Dateien man nun geändert hat und was nur Rauschen ist. Nicht nur, dass es zwangsweise zu Konflikten kommt, wenn mehrere Leute an einer 500MB-großen Welt von Binärdateien arbeiten. Nein, ganz am Ende scheitert es auch am menschlichen Konflikt. Der Eine kann sich so viel nicht merken - ok, muss ich akzeptieren. Der Andere liest grundsätzlich nicht, was auf den Bildschirm steht, klickt einfach nur alle Fehlermeldungen in Panik ab und beschwert sich dann, dass das Spiel nicht mehr startet. Urg.

Mit Unwissen kann ich umgehen. Mit übermäßigem Selbstvertrauen OHNE JEDEN GRUND habe ich aber ein ernsthaftes Problem.

[dot]

Aber ich vermute mal das ein ; auch einen Sequenzpunkt setzt (ganz dünnes Eis, sorry. Jedenfalls tut es sowas ähnliches wie , was die Programmreihenfolge betrifft) und mir ist nie so richtig klar geworden wo man das was , weniger / anders tut als ; auch genauso brauchen würde.

, ist ein Operator ; schließt ein Statement ab. In beiden Fällen gibts dort einen Sequence Point, das ist korrekt. Das ist auch einer der Gründe warum man sehr vorsichtig damit sein sollte, den , Operator zu überladen. Denn bei einem überladenen , gibts keinen Sequence Point mehr...

[antisteo]

- Warum wollen (fast) alle, dass meine Software auch auf Windows läuft?
- Wenn ich gewisse Sachen schon portieren soll, warum ist dann ein Programm nicht in der Lage, seinen bin-Ordner selbstständig in die PATH-Variable einzutragen? Das ging doch unter DOS auch ganz super mit einer neuen Zeile in der autoexec.bat
- Warum kann sich Microsoft in Sachen CLI nicht mal ein Beispiel an Linux/Unix/Bash nehmen? Sind die sich zu fein dazu? Oder haben die nicht genug Entwickler, um eine Entwicklerfreundliche Umgebung bereitzustellen?

[eXile]

Warum kann sich Microsoft in Sachen CLI nicht mal ein Beispiel an Linux/Unix/Bash nehmen? Sind die sich zu fein dazu? Oder haben die nicht genug Entwickler, um eine Entwicklerfreundliche Umgebung bereitzustellen?

Siehe PowerShell. ;)

[antisteo]

Warum kann sich Microsoft in Sachen CLI nicht mal ein Beispiel an Linux/Unix/Bash nehmen? Sind die sich zu fein dazu? Oder haben die nicht genug Entwickler, um eine Entwicklerfreundliche Umgebung bereitzustellen?

Siehe PowerShell. ;)

Setzt die mir auch gleich die korrekten Pfade, wo Includes und Libraries gesucht werden?
Oder kann die auch meine ganz normalen Makefiles abarbeiten?

[dot]

Setzt die mir auch gleich die korrekten Pfade, wo Includes und Libraries gesucht werden?

Ne Shell ist kein Buildsystem.

Oder kann die auch meine ganz normalen Makefiles abarbeiten?

:shock: *Auf die Uhr schaut* <- Ne die läuft immer noch vorwärts... :)

[kaiserludi]

- Warum wollen (fast) alle, dass meine Software auch auf Windows läuft?

Schau dir die Marktanteile der OS auf PCs an, dann weißt du warum :roll:

[Krishty]

Ich hasse schnelle, sparsame CPUs und fette, managed Sprachen

Dass die Systeme heute eine nie dagewesene Menge an Scheiße pro Sekunde und Watt fressen ist der Hauptgrund dafür, dass sich jeder Eimer Programmierer schimpfen kann und damit dafür, dass die Software-Qualität immernoch so extrem unterirdisch ist

Dafür, dass ich mir angewöhnen muss, mein Telefon vom Strom zu trennen und wieder anzuschließen, wenn die Uhr falsch läuft

Dafür, dass mein Handy einfach mal einen Tag lang nicht anspringen will

Dafür, dass die Mikrowelle sechs Tastendrücke erfordert, um meinen Fraß warm zu machen

Dafür, dass die „Produkte“ von Elektronikkonzernen – insbesondere Handys, Drucker, Digitalkameras – trotz mittlerweile vertausendfachter Rechenleistung immernoch so langsam, sperrig und nutzlos sind wie 1995, aber dafür tausend Mal bunter

Dafür, dass ich meiner Tante jede Woche aufs Neue die Toolbars aus dem Browser schubsen muss

Dafür, dass ich einen Großteil meiner Zeit aufbringen muss, die Scheiße von den Wänden zu kratzen, die andere jubelnd in den Ventilator geschissen haben

Während sie im Nebenraum eine Turbine aufbauen

[Chromanoid]

Hat ein Großteil allen Übels nicht seinen Ursprung eher darin, dass Programmierer und solche die es sein wollen eben nicht managed Sprachen verwenden? :D

Und nun mein Gejammer: Wieso bin ich immer wieder Opfer meiner pathologischen Tendenz zur Prokrastination, obwohl ich schon seit Jahren nach Mitteln dagegen suche? Ich hab schon fast die Vermutung dass ich süchtig nach dem Crunch-Time Kick bin :(.

[CodingCat]

There is no more DirectX SDK. Its various useful components have been spun out into a hodge-podge of other places, and some pieces are simply discontinued. Everything outside DirectX Graphics is of course gone, and has been for several years now. That should not be a surprise.
[...]
In case it’s not obvious, this means that the DirectX release schedule is now the same as the Windows SDK, which always corresponds with major OS updates (service packs and full new versions). Don’t hold your breath on bug fixes. Last I heard, there’s only one person still working on the HLSL compiler.

So eine Überraschung! ;)

[dot]

Also ich hab schon seit einiger Zeit drauf gewartet dass das passiert ;)

[Aramis]

So eine Überraschung!

Krishty, hol die Voodoo-Puppe raus :-)

[Krishty]

Warum? Bereitet mir mehr Freude als Wut.

Ist schließlich die Schuld der OpenGL’ler (wenn freie, plattformabhängige APIs auch nur einen feuchten Kehricht wert wären, hätte Microsoft zu viel Konkurrenz, um Direct3D so verwahrlosen zu lassen), und ich freue mich schon darauf, wie die Langhaarigen jetzt mit ihren filzigen Fingern auf die Direct3D’ler zeigen und lachen werden, weil ihre API nun empirisch beweisbar ultimativ überlegen ist – schließlich arbeitet da mehr als eine Person am Compiler!.

[eXile]

plattformabhängige APIs

Plattformabhängige oder -unabhängige? Cleverer Verschreiber, den ich nicht kapiere, oder Flüchtigkeitsfehler? ;)

schließlich arbeitet da mehr als eine Person am Compiler!.

Du meinst wohl an Compilern, wo wir auch schon bei einem Quell des Übels wären.

[antisteo]

Mesa hat seinen i965g Treiber rausgeschmissen. Dadurch werden die Intel-Treiber mit ihren vollzeitlichen Mitarbeitern davonschweben was die OpenGL-Implementierung angeht.


Mesa hat seinen Windows-Treiber rausgeschmissen.

Wenn man sich den Commit durchliest, sieht man erst mal, dass die im Prinzip ein Haufen Funktionen wrappen musste, weil Windows keine Dateien für stdin und stdout hat.

Dasselbe Problem ist auch zur Zeit der Blocker, warum ich den Executable-Mode von gwscript noch nicht portieren konnte. (hätte einer Wrapper-Bibliothek für Konsolenausgabe bedarft)

[Lynxeye]

Mesa hat seinen i965g Treiber rausgeschmissen. Dadurch werden die Intel-Treiber mit ihren vollzeitlichen Mitarbeitern davonschweben was die OpenGL-Implementierung angeht.

Schwachsinn. Die OpenGL Implementierung liegt schon immer im CoreMesa, welche auch weiterhin für Gallium als StateTracker genutzt wird. Alles was die Intelentwickler zur OpenGL Implementierung beitragen ist damit immer noch in Gallium nutzbar, egal ob es nun einen verrottenden i965g Treiber gibt, oder nicht.

[Krishty]

AMD haben an ihrem Shader Compiler gepfriemelt. Der Registerverbrauch ist gegenüber letztem Jahr um etwa 30 % gesunken, und auch ein oder zwei Prozent der Anweisungen sind raus. Obwohl immernoch suboptimal, sollte man nun bessere Leistung erwarten können. Aber arschlecken – meine Sternendemo ist nur noch halb so schnell wie letztes Jahr. Ich komme hier nicht mehr über 20 fps in Full HD hinaus; letztes Jahr waren es 40.

Viel schneller wäre es eh nicht geworden, weil der Compiler immernoch die falschen Befehle zum Laden aus dem Speicher einsetzt und ich deshalb auf ein Achtel der Bandbreite limitiert bleibe. Ich habe auch keine Lust mehr, nachzuforschen, was da wieder schiefgelaufen ist und ob das nun am Compiler, Treiber, DWM oder sonstwas liegt. Ich habe es einfach satt.

[kimmi]

Du solltest bei denen als Berater arbeiten. Offensichtlich kennst du dich in deren Shadern bald besser aus als die selber :).

Gruß Kimmi

[antisteo]

- Windows 8 unterstützt immer noch kein .tar.gz
- LLVM 3.0 muss man sich für Windows selber kompilieren. Da ich mich eh nur minimal mit Win auseinandersetzen will, ist das ein zusätzlicher Schock.
- Die Ordnerstruktur von Windows 8 ist ein Graus.
- Dateien werden nicht richtig mit ihrer Erweiterung verknüpft, also muss ich die .exe selber auf meinem Rechner suchen.
- In Windows 8 kann man die Konsole nicht verbreitern
- perl ist weder in Windows noch in MinGW installiert noch per mingw-get installierbar.
- Die Win8-Konsole kann nicht scrollen
- Markieren ist zu umständlich
- Windows braucht Click-On-Focus
- Ich habe nur eine Arbeitsfläche

[Krishty]

• LLVM 3.0 muss man sich für Windows selber kompilieren. Da ich von Software erwarte, dass ich sie direkt benutzen kann ohne erst eine Build-Umgebung aufzusetzen, CMake zu installieren und dann stundenlang zu kompilieren, hält mich das schon ewig davon ab, endlich auf Clang umzusteigen.

[antisteo]

• LLVM 3.0 muss man sich für Windows selber kompilieren. Da ich von Software erwarte, dass ich sie direkt benutzen kann ohne erst eine Build-Umgebung aufzusetzen, CMake zu installieren und dann stundenlang zu kompilieren, hält mich das schon ewig davon ab, endlich auf Clang umzusteigen.

Ist ja unter Linux alles kein Problem, sagt man make und los gehts. Was mich aber stört ist, dass man in Windows erst umfangreiche IDEs installieren muss, PATH-Variablen setzen, Bibliotheken in verschachtelte Ordner stopfen muss..
Einer der Gründe, warum ich immer noch kein C++ benutze.

[dot]

Ist ja unter Linux alles kein Problem, sagt man make und los gehts. Was mich aber stört ist, dass man in Windows erst umfangreiche IDEs installieren muss, PATH-Variablen setzen, Bibliotheken in verschachtelte Ordner stopfen muss..

Wenn du PATH Variablen setzen musst, dann ist das Buildsystem von dem konkreten Projekt einfach Müll, da kann Windows nix dafür.
IDEs installieren!? Alles was du brauchst: http://www.microsoft.com/download/en/de ... px?id=8279

[antisteo]

Ist ja unter Linux alles kein Problem, sagt man make und los gehts. Was mich aber stört ist, dass man in Windows erst umfangreiche IDEs installieren muss, PATH-Variablen setzen, Bibliotheken in verschachtelte Ordner stopfen muss..

Wenn du PATH Variablen setzen musst, dann ist das Buildsystem von dem konkreten Projekt einfach Müll, da kann Windows nix dafür.
IDEs installieren!? Alles was du brauchst: http://www.microsoft.com/download/en/de ... px?id=8279

Wozu brauch ich das komplette .NET SDK, um eine einzige C++-Datei zu kompilieren? Das sind schon wieder hunderte MB an Software, wobei ja VisualStudio schon auf dem Win8 Developer Preview drauf ist.

[Krishty]

Die 80-Bit-Präzision der FPU ist kein Feature, sondern ein Ärgernis. Zum einen sind die acht Register viel zu wenige und zu unhandlich, so dass der Compiler die Zwischenergebnisse eh dauernd mit 64-Bit-Präzision auf den Stapel zurückwirft. Die einzigen Situationen, in denen die 80-Bit-Präzision greift, sind die, in denen man sie nicht gebrauchen kann – etwa bei exakten Vergleichen à la cos(0.1) == cos(0.1).

x64 macht es zum Glück richtig. Obwohl „nur“ mit 64-Bit-Präzision gerechnet wird, ist die Fehlerabweichung hier nicht größer als unter x86 – vermutlich, weil x86s Stapelpush- und -Popperei die 80 Bits komplett zunichte macht. (Ich muss aber auch zugeben, dass ich keine hochpräzise Berechnung für den Fehlerwert heranziehe.) x64 mit seinen 64 Gleitkommaregistern ist dagegen the shit. Im Augenblick gibt es unter meinen Basisgeometriefunktionen keine einzige, die Zwischenergebnisse auf dem Stapel ablegt – es läuft alles komplett durch die Register. Genau, wie es sein sollte.

[Krishty]

Meine Freude über Visual C++’ x64 Code Generation vor einigen Wochen hat sich mittlerweile gelegt. Die Optimierung mag vielleicht nicht mehr so katastrophal wie unter x86 sein, hat aber immernoch ihre Macken.


Zum einen wäre da das ewige Outsourcen von Konstanten zu nennen. Nehmen wir mal dieses unscheinbare Stückchen Text:

double x = …;
double y = 2.0 * x;

Was der Compiler bei der Verdopplung tun wird, ist: Er wird im Datensegment acht Bytes mit dem Hex-Wert 0x4000000000000000 anlegen (entspricht der double 2.0); wird sie zur Laufzeit von dort laden und x damit multiplizieren.

WTF?! Ein globaler Speicherzugriff, um einen Wert zu verdoppeln?!
Kann ja sein, dass x64 keine Möglichkeit bietet, 64-Bit-Gleitkommakonstanten direkt im Befehlsspeicher unterzubringen – nachgeguckt habe ich nicht. Aber mit Ganzzahlkonstanten wird das die ganze Zeit gemacht; kann man dann nicht zumindest die 0x4000000000000000 in ein Ganzzahlregister schreiben und von dort in die xmms schieben? Ich meine: Cache kostet doch und so …


Mit globaler Wirkung scheint VC sowieso seine Probleme zu haben. Eine Funktion foo(), die keine globale Wirkung hat und keine Speicherzugriffe außerhalb des Stapels durchführt (; die nicht einmal Konstanten benutzt ;) ), wird nicht wegoptimiert, falls mit dem Ergebnis nichts angefangen wird.

Das bedeutet: Wird dieses foo() in einer Schleife aufgerufen, die mit dem Ergebnis garnichts anstellt – ist es also eindeutig überflüssig – wird das nicht wegoptimiert. Die Funktion wird einfach ganz heiter weiterdurchlaufen; wieder und wieder und wieder und bewirkt absolut … garnichts. I can't even … aber ausgeglichen wird es zum Glück dadurch, dass Funktionen manchmal sogar wegoptimiert werden, obwohl sie Wirkung haben.

[CodingCat]

if (id == token_type::tok_obrace) - Ich kann gerade nicht glauben, dass mich VC++ nicht mal warnt, wo id vom Enum-Typ operator_id, tok_obrace jedoch vom Enum-Typ token_type ist.

[joggel]

Gerade getestet... ich bin ebenfalls entsetzt!!

[dot]

Btw: token_type::tok_obrace ist non-standard. Zumindest wenns kein strongly typed enum ist (die MSVC afaik noch net unterstützt), dann ist der Scope der Konstanten nämlich der Scope der das enum enthält und nicht der enum selbst. ;)

[kaiserludi]

Der Clang static analyzer ist so schlecht :(

Code: Alles auswählen

if(!size)
	return NULL;
data = MALLOC(size*sizeof(void*));
for(i=0; i<size; i++)
	innerArray = deserializeArray(op);
sizes = MALLOC((innerArray->dimensions+1)*sizeof(short*));

Da meint er doch glatt:
"Access to field 'dimensions' results in a dereference of a null pointer (loaded from variable 'innerArray')".
Der einzige Fall, in dem innerArray NULL sein kann, ist, wenn size 0 ist, weil er dann nicht in die for-Schleife springt. In dem Fall returnt er aber vorher und greift gar nicht auf dimensions zu...

EDIT:
Und noch so ein toller Fund (Code ist zum einfacheren Verständnis vereinfacht, der Fehlalarm schlägt aber auch in dem vereinfachten Schnipsel an):

Code: Alles auswählen

short i;
if(!pData && arraySizes[recursionDepth]) // arrays of size 0 are intended to have a NULL-pointer as data!
	return false;
for(i=0; i<arraySizes[recursionDepth]; i++)
	((void**)pData)[i];

"Array access (from variable 'pData') results in a null pointer dereference"