Jammer-Thread

[Artificial Mind]

Ja, mir war schon klar was du meintest, war ja auch nur scherzhaft gemeint ;) Aber hast natürlich Recht, gibt genug Leute, die erstmal den Compiler verantwortlich machen, ist ja schließlich der erste in der Kausalkette^^ Bei YADC hatte ich sehr lange einen Fehler in den Partikeln, bei dem die Masse der Partikel mit sich selbst anstatt dem übergebenen Parameter initialisiert wurde, unter MSVC ging alles Prima, weil es irgendeinen Wert bekommen hatte mit dem sich weiterrechnen ließ, unter GCC gabs häufiger 0 oder NaN und keine Partikel mehr...

[FredK]

Ich wollte ja nicht dem Compiler die Schuld geben. Ich hab nur in meiner Verzweiflung so laut gejammert. :? :? Danke für die tröstenden Worte. Vielleicht finde ich ja noch was. Das blöde ist, dass die Berechnungen sich über hunderte Zeilen Code hinziehen, die aus anderen Bibliotheken oder meinen Teamkollegen kommen und die ich ja nicht geschrieben hab (und für vorerst richtig angenommen hatte). :( Mal sehen, ob ich da noch was finde.

[CodingCat]

Warum sollte der Zugriff auf meinen Notenauszug nicht auch mal wegen einer NullReferenceException unmöglich sein.

[dot]

Vielleicht hast du was Besseres als eine Eins bekommen ;)

[klickverbot]

Ich hatte (laut Webinterface) mal einen Notenschnitt von 0.9 – an einer Uni, an der Informatik das beliebteste und Mathematik ein wichtiges Studienfach ist… xD

[Krishty]

Windows Update ist nun endgültig aus – ich bin zum vierten Mal nach dem Essen zurückgekommen und alles war weg, weil der Neustart-Countdown auslief, während der Rechner gesperrt war. Das ist der Punkt, wo ich das Malware-Risiko geringer einschätze als die Zeit, die mir jedes Mal verlorengeht, wenn Microsoft nicht begreift, dass ich bis zum Wochenende warten will um deren verficktes .NET Arschwork zu aktualisieren, das ich sowieso für keine andere Anwendung brauche als das hoch sicherheitskritische MSBuild von Visual C++ und den AMD-Treiber, den ich eh nach jedem Systemstart als Erstes mit Admin-Gewalt aus dem Task-Manager boxe.

[Helmut]

10 Sekunden googeln bringen mehr als jammern ;)
http://www.howtogeek.com/howto/windows- ... -computer/

Ciao
Helmut

[Andre]

2 GB meines Arbeitsspeichers haben sich heute wohl verabschiedet. Fühlt sich gar nicht gut an nun einen kastrierten PC zu haben :(

[Krishty]

10 Sekunden googeln bringen mehr als jammern ;)
http://www.howtogeek.com/howto/windows- ... -computer/

Das bringt nichts. Der Rechner startet sich dann zwar nicht autonom neu, aber die Updates sind bereits aufgespielt und damit sind alle betroffenen Assemblies gesperrt – was für mich z.B. bedeutet, dass ich nicht kompilieren kann, weil MSBuild seine Abhängigkeiten nicht mehr laden kann. Dann kann ich zwar noch schnell speichern, aber neustarten muss ich trotzdem. Tatsächlich beginnt der Schaden schon mit der Installation der Updates; nicht erst mit dem Neustart danach.

2 GB meines Arbeitsspeichers haben sich heute wohl verabschiedet. Fühlt sich gar nicht gut an nun einen kastrierten PC zu haben :(

Ich wusste garnicht, dass man das heute noch merken kann ;)

[Andre]

2 GB meines Arbeitsspeichers haben sich heute wohl verabschiedet. Fühlt sich gar nicht gut an nun einen kastrierten PC zu haben :(

Ich wusste garnicht, dass man das heute noch merken kann ;)

Wenn man eh nur 4GB drin hatte merkt man es. Hatte damals (letzten Sommer) einfach nicht genug Kohle mir nochmal 4 zu holen. "Heutzutage" ist RAM ja verdammt günstig geworden, und ich denke ich werd mir beim Umtausch nochmal direkt ein wenig dazu bestellen ;)

[Krishty]

char buf[n];
DWORD bytesRead;
ReadFile(GetStdHandle(STD_INPUT_HANDLE), buf, sizeof(buf), &bytesRead, nullptr);

Das schlägt mit der Konsole fehl, wenn buf größer ist als 31346 Bytes. Und bytesRead ist garkein optionaler Parameter – übergibt man hier nullptr, stürzt das Programm in Kernel32.dll ab.

Wtf, Microsoft?!

[dot]

Und bytesRead ist garkein optionaler Parameter – übergibt man hier nullptr, stürzt das Programm in Kernel32.dll ab.

This parameter can be NULL only when the lpOverlapped parameter is not NULL.

;)

[Krishty]

Autsch. Niemals mit Kater stänkern.

[glassbear]

OH GOTT IST DAS ENDE VON MASS EFFECT 3 MIIIIEEESS


Und mein PC installiert seit 2h Visual Studio. Und jetzt Service Pack 1 dafür. Danach brauch ich sicherlich noch lauter sicherheitskritische Updates für das Ding, nur damit ich ein kleines Projekt mal kompilieren kann :roll: :roll: :roll:

Edit: Und da poppt Windows Update mit ZWEI sicherheitskritischen Updates von Visual Studio auf. 280MiB Download WTF???

[Schrompf]

Ich habe schon wieder das Problem, dass dieser Trottel von einer GPU meine PixelShader-Ausgabewerte auf 0 bis 1 clampt, obwohl ich in ein Float16-Rendertarget zeichne. Und anscheinend bin ich mit diesem Problem echt der Einzige auf der Welt.

[dot]

Was für eine Pixel Shader Version verwendest du denn? Bist du dir sicher dass das Clamping erst bei der Ausgabe passiert?

[CodingCat]

Pixel Shader Inputs
For pixel shader versions ps_1_1 - ps_2_0, diffuse and specular colors are saturated (clamped) in the range 0 to 1 before use by the shader.

Hier könnte Clamping z.B. tatsächlich schon in der Interpolation auftreten, in diesem Fall TexCoord#- statt Color#-Semantic bei der Weitergabe von VS zu PS benutzen.

Auch mit manchen unüblicheren Alpha-Blending-Konfigurationen hatte ich für Werte außerhalb des Intervalls [0..1] schon ab und an Probleme.

[dot]

Genau darauf wollt ich hinaus. Ich bin früher ziemlich oft in diese Falle getappt. Evtl. verwendet ein problematischer Parameter eine COLOR Semantik? Übergeb den mal als TEXCOORD.
Die Frage ist allerdings welche Shader Model 1.x Karte fp16 Targets unterstützt...

[Chromanoid]

Ich meine mich ganz dunkel daran zu erinnern, dass ich mal so ein ähnliches Problem hatte und die Werte irgendwie normalisiert wurden (sofern ich mich wirklich richtig erinnere), aber das hättest du sicher gemerkt.

[Andre]

Ein Auszug meines kleinen Testcontrollers für die Pulsedrive-Schiffe. Seit schon längerer Zeit frage ich mich, warum das Uprighting nicht mehr klappt.

Code: Alles auswählen

class TestController2 : GlobalScriptBase
{
	// [Viele Variablen]
	float UprightFactor;

	/** Called on mapload */
	void OnLoad()
	{
		// Create springs
		float DefStiffness = 680;
		float DefDamping = 0.6f;
		float DefLength = 1.0f;
		float DefRestLength = 4.0f;
	
		float MainFrontOffset = -1.8f;
		float MainBackOffset = 1.5f;
		float MainSideOffset = 0.8f;
		float MainHeight = 0;
		float UprightFactor = 600000.0f; // <---
		
		// [...]
	}

Soviel dazu :D

Edit: Mein Code wird gar nicht so eingerückt wie im Editor gezeigt :(

[CodingCat]

Deshalb plädiere ich auch heute noch für altmodische m_- und g_-Präfixe. Sie mögen hässlich sein, aber sie erzwingen zumindest konsequent eine bewusste Auswahl des Kontexts. :|

[Andre]

Leider wahr :|

[CodingCat]

150 MiB für den Basis-Druckertreiber. Nicht das verschissene Software Bundle. Das läge vermutlich irgendwo bei 1 - 2 GiB. Der Treiber, den ich noch immer mit der Machete in der Hand dem HP-Jungle entreißen muss. Vermutlich, weil die Software sämtliche offiziellen Windows-Update-Treiberrichtlinien sprengen würde.

(Ja, ich weiß, Druckertreiber gehörten schon immer zur schlimmsten System-Software überhaupt. Dies ist ein Kampf gegen das Vergessen. Dass dieser Treiber vor nicht allzu langer Zeit noch alleine 2 HDDs gefüllt hätte. Dass die Entwicklung schleichend und doch unaufhaltsam vonstatten geht. Und so werde ich mich auch in ein paar Jahren wieder hier empören. Wenn mein Basis-Druckertreiber zwischen 1 und 2 GiB verschlingen wird.)

[Biolunar]

150 MiB für den Basis-Druckertreiber. Nicht das verschissene Software Bundle. Das läge vermutlich irgendwo bei 1 - 2 GiB. Der Treiber, den ich noch immer mit der Machete in der Hand dem HP-Jungle entreißen muss. Vermutlich, weil die Software sämtliche offiziellen Windows-Update-Treiberrichtlinien sprengen würde.

(Ja, ich weiß, Druckertreiber gehörten schon immer zur schlimmsten System-Software überhaupt. Dies ist ein Kampf gegen das Vergessen. Dass dieser Treiber vor nicht allzu langer Zeit noch alleine 2 HDDs gefüllt hätte. Dass die Entwicklung schleichend und doch unaufhaltsam vonstatten geht. Und so werde ich mich auch in ein paar Jahren wieder hier empören. Wenn mein Basis-Druckertreiber zwischen 1 und 2 GiB verschlingen wird.)

Kenne ich. Unser Drucker hat unter Windows auch einen Treiber von >100MB. Selber Treiber unter Linux: 6MB … Da ist doch irgendetwas faul.

[kaiserludi]

Deshalb plädiere ich auch heute noch für altmodische m_- und g_-Präfixe. Sie mögen hässlich sein, aber sie erzwingen zumindest konsequent eine bewusste Auswahl des Kontexts. :|

Wir nutzen auf meine Initiative hin inzwischen konsequent m, g und p a als Prefixed wie in mMemberVariable, gGlobalVariable, pPointer, aber nichts darüber hinaus, also keine ungarische Notation oder so etwas.
Sehe keinen Sinn in dem_ zwischen prefix und Variablennamen, sieht nur hässlich aus und lässt alle Variablen jedes mal einen Character mehr Platz in der Zeile benötigen.

[CodingCat]

Sehe keinen Sinn in dem_ zwischen prefix und Variablennamen, sieht nur hässlich aus und lässt alle Variablen jedes mal einen Character mehr Platz in der Zeile benötigen.

Joa, das wiederum ist mir absolut egal. Die Länge von Variablennamen ist für mich kein Problem, der Unterstrich reine Gewohnheit. Seit ich auch m. und m-> für Attribute habe, fügt sich diese Gewohnheit außerdem zufällig hervorragend in mein Quelltextbild. p bin ich leider auch noch nicht ganz los, wobei es praktisch immer unnötig ist. In letzter Zeit versuche ich, p etwas mehr Bedeutung zu verleihen, indem ich es für <potentiell nullptr> einsetze. Mangels einheitlicher Verfolgung von Beginn an ist das allerdings auch mehr der Versuch meinerseits, eine eigentlich überflüssige Gewohnheit doch noch irgendwie zu rechtfertigen.

[kaiserludi]

p finde ich praktisch, um auch in jeder noch so schelchten IDE und auch rein im Texteditor immer sofot zu sehen, ob ich . oder -> schreiben muss bzw. var oder *pVar.

[CodingCat]

p finde ich praktisch, um auch in jeder noch so schelchten IDE und auch rein im Texteditor immer sofot zu sehen, ob ich . oder -> schreiben muss bzw. var oder *pVar.

... sofern du dich erinnerst, ob es var oder pVar war. Und sobald du dich daran erinnerst, weißt du auch, ob du . oder -> schreiben musst. Ich habe aufgehört, mich mit derlei Argumentation selbst zu verschaukeln. :mrgreen:

Aber letztlich ist Namensgebung ein Non-Issue. Ich habe kein Problem damit, mich jeder Konvention anzupassen. Selbst mit vollkommen präfixfreier Namensgebung lässt sich sicher umgehen, indem man einfach konsequent immer zu this-> oder :: zur Auswahl des richtigen Kontexts greift.

[kaiserludi]

p finde ich praktisch, um auch in jeder noch so schelchten IDE und auch rein im Texteditor immer sofot zu sehen, ob ich . oder -> schreiben muss bzw. var oder *pVar.

... sofern du dich erinnerst, ob es var oder pVar war. Und sobald du dich daran erinnerst, weißt du auch, ob du . oder -> schreiben musst. Ich habe aufgehört, mich mit derlei Argumentation selbst zu verschaukeln. :mrgreen:

Aber letztlich ist Namensgebung ein Non-Issue. Ich habe kein Problem damit, mich jeder Konvention anzupassen. Selbst mit vollkommen präfixfreier Namensgebung lässt sich sicher umgehen, indem man einfach konsequent immer zu this-> oder :: zur Auswahl des richtigen Kontexts greift.

Ich muss mich eben nicht daran erinnern, da es mir ja der Prefix jederzeit verrät.
Wenn du der einziger Programmierer an dem projekt bist, kannst du ja auch in der Regel alleine die Namensgebung bestimmen, bist du es hingegen nicht, dann müssten sich alle anderen auch daran halten, konsequent immer this-> und :: zu schreiben, denn gerade bei Code, den man nicht wie seine Westentasche kennt, bringt sowas ja am meisten, und da wird man sie noch weit eher von Präfixen überzeugen können.

[CodingCat]

Ich muss mich eben nicht daran erinnern, da es mir ja der Prefix jederzeit verrät.

Du musst dich daran erinnern, dass die Variable ein Präfix hat. ;-)

Wenn du der einziger Programmierer an dem projekt bist, kannst du ja auch in der Regel alleine die Namensgebung bestimmen, bist du es hingegen nicht, dann müssten sich alle anderen auch daran halten, konsequent immer this-> und :: zu schreiben, denn gerade bei Code, den man nicht wie seine Westentasche kennt, bringt sowas ja am meisten, und da wird man sie noch weit eher von Präfixen überzeugen können.

Genau davon rede ich doch, wenn ich nicht der einzige Programmierer bin, kann ich die Namensgebung in der Regel auch nicht beeinflussen. Dann muss ich auch niemanden überzeugen, sondern selbst einen Weg finden, damit optimal umzugehen. Und wäre die vorgegebene Konvention, keinerlei Präfixe einzusetzen (und ich denke, es gibt da draußen heute etliche Firmen, die in dieser Richtung zum Beispiel die JCC durchsetzen), dann wäre die konsequente explizite Auswahl des Kontexts in dem Code, den ich selbst für diese Firma schreiben müsste, eben die verantwortungsvollste Art und Weise, damit umzugehen.

Genau das meine ich, wenn ich sage, Namensgebung ist ein Non-Issue. Unabhängig von den Vorschriften zur Namensgebung findet sich fast immer ein Weg, sicher damit umzugehen, auch wenn dieser Weg vielleicht von anderen in diesem Rahmen gängigerweise nicht verfolgt wird. Aber das ist dann nicht mein Problem, es sei denn, ich muss deren Code warten. Und in diesem Fall kriege ich für deren Mist ja sogar Geld. ;-)

Gehöre ich hingegen zu denjenigen, die die Namensgebung beeinflussen können, dann wähle ich natürlich die Namensgebung, die von sich aus für alle im Alltagsgebrauch das kleinste Risiko birgt. Und in diesem Fall sind wir uns bezüglich Präferenzen ja offensichtlich weitestgehend einig.