Jammer-Thread

[Chromanoid]

Ah den Trick kannte ich noch gar nicht. Ich verwende immer die Kommandozeile für mit . geschützte Ordner.

[marcgfx]

Mein Computer zeigt nur noch schwarz an. Vermutlich ist das Motherboard oder die Graphikkarte kaputt. Hab friedlich was gegessen und ein dämliches Youtube Video gekuckt. Dröhnende Lautsprecher, ein schwarzer und ein weisser Monitor haben mir den Mittag versaut. Wie ich das hasse :(

[marcgfx]

pc startet wenn ich die grafik-karte ausstecke, problem wird wohl da sein. kurz bevor das problem auftrat sah ich noch ne asus-installationsmeldung. vermutung treiber. also alle deinstalliert. leider startet der pc weiterhin nicht mehr, wenn die grafikkarte saft hat. wie soll ich da neue treiber installieren?

asus support hat mir geraten einen anderen slot zu probieren (motherboard auch von asus, modell habe ich mitgeteilt). Da flog doch prompt die sicherung raus, war wohl nicht so eine gute idee. motherboard hats überlebt. muss mir wohl ne neue grafikkarte organisieren.

[DerAlbi]

Also meinem Elektronik-Grundverständnis nach darf keines Falls die 16A Hauptsicherung kommen, nur weil man eine Grafikkarte umsteckt. Die Schaltnetzteile in einem PC sind intrinsisch kurzschlussicher, das bedeutet: du kannst die 5V, 3.3V und die 12V kurzschließen oder sogar die 12V auf die 5V-Schiene geben und alles, was passiert ist, dass eine elektronische Sicherung (Fehlererkennung) anspringt und das Netzteil ausmacht (oder das stimmt nicht; und meine Erfahrungen dahingehend sind die gute Seite der Ausnahmen).
Das gilt auch ohne Kurzschluss für Überstrom usw... einen sekundärseitigen Kurzschluss sollte man auf der Primärseite gar nicht sehen :-/
Bedeutet: wenn du kein mega ****** Netzteil hast, ist der Fehler nicht nur in der GraKa zu suchen. (Meiner Meinung nach)
Das Probelm ist: die Primätseite eines Schaltnetzteils ist überhaupt nicht darauf ausgelegt solch einen 16A-Fehlerstrom überhaupt zu erzeugen, noch zu überleben.
Falls du eine neue GraKa reinbaust... ööhmmm miss mal die 12V vorher nach oder wechsel gleich das Netzteil mit, falls du eins rumliegen hast...


Wenn ich schonmal poste:
Die Wärmeleitpaste auf meiner CPU war eingetrocknet. Sehr interessantes Phänomen. Das Tolle: dabei hat die extrem gut den Prozessor mit dem Kühlkörper verklebt.. und zwar so, dass weder Hebeln noch Schraubenzieher noch sonst irgendeine mechanische Kraft, die man an einer 500€ CPU aufbringen mag, geholfen hat. Mechanisch also top verbunden, thermisch leider nicht so mega :|
Nunja. Aber irgendwie muss man es lösen... Also... eine beherzte Drehbewegung am Kühlkörper (wurde im internet vorgeschlagen(TM)) und es war geschehen - Die Klebeverbindung war hinüber.. aber nicht nur das :-D. Neben komplett verbogenen Heatpipes ist mit der CPU-Sockel komplett zerbrochen... juhuuu aber die CPU hats überlebt :-)
Nach einer anstrengenden mechanischen Reinigung des Klebstoffs, äääh der alten Wärmeleitpaste, neue Paste drauf und gleich ne WaKü. Die CPU sitzt nun leicht fragwürdig im Sockel.. quasi handplatziert mit etwas gutem Willen. Das hat nach dem ~8. Versuch tatsächlich geklappt.
Irgendwie geht noch alles, außer so ein paar komische Sachen, wie die ganze Sensorik.. die ist hinüber. Mein Mainboard hat durchschnittlich -11°C... meine CPU spannnung hat grade 1.5V :-D die 5V-Schiene wird als 6.12V angezeigt und die 12V sind auf 13.5.. aber herjeeh scheiß drauf. Die CPU läuft.
Ist bischen wie bei modernen Auto... die selbst gehen kaum kaput, aber die Sensorik, die Defekte erkennen soll, bedarf Wartung...
Die neue WaKü ist aber Top. 6x 4.4GHz bei nur 80°C

[Krishty]

Ich bastle gerade für meine Retro-Projekte einen ILBM-Viewer. Das war das am weitesten verbreitete Bildformat der Amiga-Ära. Leider kann z.B. IrfanView keine exotischen Variationen davon laden, und libilbm und was es sonst noch gibt ist alles unvollständig. Weil ich ja eh schon einen Viewer für ein paar PlayStation-1-Dateien habe, packe ich also noch ILBM dazu.

Boah ist das ein Verschachtelungshorror. Ich zähle 105 Verzweigungen im ladenden Code. Am tollsten sind die Pixelformate:

• 0 Bits Farbtiefe mit Palette bedeutet, dass gar kein Bild in der Datei vorhanden ist, sondern dass es nur eine Palette transportiert.
• 24 und 32 Bits Farbtiefe sind RGB(A) und damit die einfachsten Fälle.
• 1–8 Bits Farbtiefe bedeuten, dass eine Palette benutzt wird.
• außer 8 Bits Farbtiefe ohne Anwesenheit einer Palette – denn das ist eine Graustufendatei.
• 5 oder 6 Bits Farbtiefe mit einer 16er-Farbpalette bedeuten Hold and Modify-Grafikmodus (eine Art zeilenweise Deltakompression).
• ebenso 7 oder 8 Bits Farbtiefe mit einer 64er-Palette.
• 6 Bits Farbtiefe mit 32er-Palette bedeuten Extra-Halfbrite, wo die verbleibenden 32 Farben verdunkelte Versionen der ersten 32 sind.
• PBM bedeutet, dass dieser ganze Kram nicht nur als einzelne Bit-Planes vorliegen kann, sondern auch als „normale” Bitmap. Hier fällt HAM zum Glück raus.
• Davon unabhängig kann jede Zeile RLE-komprimiert sein.
• Beliebige Pixel können maskiert sein – als Color Key, als Maske (abhängig von Datenlayout als zusätzliche Bit-Plane oder nicht), oder durch Flood Filling. Aber man darf sie erst nach dem Dekodieren verwerfen, weil das sonst mit der Zeilenkompression interferiert.

Und am schönsten war dann, wie ich einen Tag vor unlesbaren Dateien gesessen habe, bevor ich merkte, dass die Beispieldateien im Internet Archive kaputt (wie in: von beschädigtem Datenträger kopiert) sind … yay.

[Schrompf]

Dafür habe ich noch uralten Loader-Code rumliegen :-) Aber der deckt nur die 1-8-Bitplane-Version ab, also weit weniger, als Du da hast. Der Großteil dieser absurden Modi ergibt sich aus den absonderlichen Fähigkeiten des damaligen Grafikchips.

[Krishty]

Der Großteil dieser absurden Modi ergibt sich aus den absonderlichen Fähigkeiten des damaligen Grafikchips.

Weil ich ja aus den hunderten Seiten Dokumentation auch was gelernt habe:

Frühe Computer wurden direkt an den Fernseher angeschlossen und arbeiteten deshalb direkt auf dem NTSC-Signal. Als die Computer noch mit zwei/vier/acht Farben arbeiteten, konnte man ein Byte Speicher (und einige Transistoren) sparen, indem man die Farbe am Anfang der Zeile setzt und danach nur noch das Helligkeitssignal überträgt (ist bei TV ja beides getrennt). Natürlich hatte man dann nur eine Farbe pro Zeile, aber … doppelte Geschwindigkeit!

Als Commodore auf RGB umstellte, entfiel diese Funktionalität. Dummerweise hatte man dann ein großes Loch mitten im Grafikchip. Der Chefingenieur meinte, das wären drei Monate Arbeit, das wieder raus zu kriegen. Also einigte man sich darauf, die Funktionalität drin zu lassen, aber sie für RGB anzupassen. Und das war dann der erste Hold and Modify-Modus, und 35 Jahre später jammert Krishty, was für ein scheiß Gewusel das im Code ist.

[dot]

Branch Prediction to the rescue... :P

[Krishty]

Die Geschwindigkeit ist mir da sogar fast egal, weil das Konvertieren von ILBM zu Bildschirmpixeln keine Echtzeitaufgabe ist (ähnlich wie nie jemand direkt aus JPG-Daten rendern würde). Nur ist es ein Wartungsalptraum, eine 300 Zeilen lange Pixelkonvertierungsroutine mit sechs Verschachtelungen in der inneren Schleife zu haben. Eine Zeile umstellen, fünf exotische Kompressionsarten gehen kaputt. Bäh.

[Alexander Kornrumpf]

Weil ich ja aus den hunderten Seiten Dokumentation auch was gelernt habe:

Frühe Computer wurden direkt an den Fernseher angeschlossen und arbeiteten deshalb direkt auf dem NTSC-Signal. Als die Computer noch mit zwei/vier/acht Farben arbeiteten, konnte man ein Byte Speicher (und einige Transistoren) sparen, indem man die Farbe am Anfang der Zeile setzt und danach nur noch das Helligkeitssignal überträgt (ist bei TV ja beides getrennt). Natürlich hatte man dann nur eine Farbe pro Zeile, aber … doppelte Geschwindigkeit!

Als Commodore auf RGB umstellte, entfiel diese Funktionalität. Dummerweise hatte man dann ein großes Loch mitten im Grafikchip. Der Chefingenieur meinte, das wären drei Monate Arbeit, das wieder raus zu kriegen. Also einigte man sich darauf, die Funktionalität drin zu lassen, aber sie für RGB anzupassen. Und das war dann der erste Hold and Modify-Modus, und 35 Jahre später jammert Krishty, was für ein scheiß Gewusel das im Code ist.

Da ich mal, allerdings nur für 10 Minuten, versucht habe zu verstehen wie EGA funktioniert kann ich so richtig respektieren, wie du dich da durchwühlst.

[Krishty]

Ich muss nichts rückentwickeln oder so; Dokumentationen gibt es zu Hauf (das AmigaOS-Wiki ist super). Aber in Implementierungsdetails sind diese Dokumentationen teils widersprüchlich (Randfarbe „Schwarz“ oder „Erster Paletteneintrag“?) und muss man sich die Wahrheit aus hunderten verstreuten Mini-Quellen zusammensuchen.

Was wirklich schwer ist, ist das Finden geeigneter Testdateien. Für Half-Brite musste ich z.B. ein 1993er Webcomic aus einer LZH extrahieren, die in einem längst stillgelegten CD-Repository eines alten BBS lag. Und diese Quellen sterben immer weiter, Tag für Tag.

[Krishty]

Da ich mal, allerdings nur für 10 Minuten, versucht habe zu verstehen wie EGA funktioniert

Boah, gut dass du EGA erwähnst. Es scheint ILBMs zu geben, die gar keine eigene Palette mitbringen, und stattdessen auf der EGA-Standardpalette arbeiten. Ich weiß, dass solche Dateien z.B. in den komprimierten Archiven von Commander Keen herumliegen; bin aber bisher an keine Kopie gekommen (Spiel suchen -> Image runterladen -> DOS-Emulator installieren -> schon wieder 5 Uhr morgens, fuck my life). Also eine weitere Verzweigung für die Jammer-Liste oben.

Wer noch so alten Kram auf der Platte liegen hat: Immer her damit! Ihr kriegt dafür natürlich auch den Viewer und die Thumbnail-Shell Extension samt Quelltext.

[Krishty]

Mein Thumbnail Handler ist 90 KiB groß. 79 KiB davon entfallen auf die Visual-C++-CRT, die überzeugt ist, folgende Dinge gehörten in mein Programm obwohl ich keinen Gebrauch davon mache:

• log10() (fast 2 KiB)
• parse_command_line(), expand_argument_wildcards(), common_expand_argv_wildcards(), usw – obwohl ich eine DLL kompiliere(!)
• memcpy – ich sehe ein, dass man das manchmal zur Initialisierung braucht; aber nicht, dass es mit 1 KiB größer ist als viele meiner Image Loader
• _raise_exc_ex(), _seh_filter_exe() und weitere Ausnahmebehandlungsroutinen – obwohl Exceptions in den Projekteinstellungen abgeschaltet sind und ich kein SEH nutze
• setmbcp_internal(), write_text_utf8_nolock(), und weiterer Locale-Dreck – obwohl ich keine stdio oder C++-I/O nutze
• __report_gsfailure() – obwohl Security Checks deaktiviert und Security Cookies durch Compiler-Switch ausgeknipst sind
• Rund fünfzig Funktionen betreffend Locks und Mutexe – obwohl ich nichts in Richtung Multithreading verwende außer _InterlockedIncrement() & Co.
• Etliche KiB unkenntlichen Mülls aus einer gewissen winapi_thunks.obj

Ich muss also dringend wieder anfangen, meine eigene CRT zu schreiben. Wirklich – fuck that shit.

So. Habe mich eine Stunde hingesetzt und eine Mini-CRT geschrieben. Alle Symbole definiert. Ich musste kranken Scheiß machen, über den ich hier später noch ausführlicher jammern werde. Und was ist die Frucht meiner Mühen?

  1>Formats ILBM.obj : error LNK2016: absolute symbol '@comp.id' used as target of REL32 relocation in section 8D

FFFFFFFFUUUUUUUUUU

Nachtrag: Alle CRT-Ersatzfunktionen in eigene .cpp schieben; globale Optimierung deaktivieren; passt. Jetzt bin ich direkt viel weiter:

Code: Alles auswählen

1>dllmain.cpp : fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 249)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information
1>    link!RaiseException()+0x58
1>    link!CxxThrowException()+0x65
1>    link!std::_Xout_of_range()+0x1f
1>    link!InvokeCompilerPass()+0x25984
1>    link!InvokeCompilerPass()+0x18c0d
1>    link!InvokeCompilerPass()+0x18b8b
1>    link!InvokeCompilerPass()+0x18fa3
1>    link!InvokeCompilerPass()+0x18f14
1>    link!InvokeCompilerPass()+0x1be23
1>    link!InvokeCompilerPass()+0x1b8d3
1>    link!DllGetC2Telemetry()+0xc7cc6

Die „location listed above“ ist die erste Zeile des Projekts (was mir wohl sagen soll, dass ich von Anfang an verschissen habe).

[Krishty]

Geschafft. Der Thumbnail Shell Extension Handler nutzt keine CRT mehr, und die Größe ist von 104 KiB auf 15 geschrumpft (64-Bit-Version!). Davon entfallen

• 4+2 KiB auf ILBM- und TIM-Decoder
• 3 KiB auf COM-Server
• ein paar KiB auf Overhead wie globale GUID-Variablen, DLL-Einsprungspunkt, Funktionsimporte, Konstanten, etc.

… und es wäre erwiesen, dass 85 % der DLL tatsächlich überflüssiger Schrott aus Visual C++’ CRT waren.

Das Ersetzen der CRT ging übrigens – selbstverständlich – nicht ohne Assembler-Quelltext. Danke, Visual C++!

[glassbear]

Ich wuerde sogar Geld bezahlen wenn du das in einen Artikel zum Nachmachen verpackst ;)

[Krishty]

Für Schritt-für-Schritt-Anleitungen habe ich keine Zeit, aber die wichtigsten Fallstricke erläutere ich hier.

[Krishty]

Visual C++ zieht ungenutzte Symbole in meine EXE. Nicht immer, aber immer öfter. Alle Fälle betreffen structs oder Arrays. Egal, ob ich sie static deklariere (C-Style) oder in ein anonymes namespace lege (C++-Style) – keine der in der EXE landenden Funktionen nutzt sie, aber sie stehen drin und verschwenden Platz. Richtig aufgefallen ist es erst, als dtoa.c ein 256 B großes Array mitbrachte, obwohl ich nirgendwo mit Strings arbeite.

Das muss ich irgendwie auf einen minimalen Repro reduzieren, aber das Wochenende ist schon wieder rum.

*Marge Simpson-Grummeln*

Nachtrag: Beschwerde über globale volatiles zurückgenommen; habe in die falsche Spalte geguckt :oops:

[gdsWizard]

Auf dem Amiga gab es noch Dynamic HAM und Dynamic HiRes. Hier wurden mit dem Copper innerhalb eines Bildes die Frabregister neu gesetzt. So ne Art Multitasking für die Farbregister.

[Krishty]

Ja, dem Archive Team nach:

There are at least three extended HAM formats designed to take advantage of the Amiga's ability to make changes to the palette in the middle of an image:

• SHAM (Sliced HAM) - Uses a SHAM chunk.
• CTBL (Newtek Dynamic Ham) - Uses CTBL and DYCP chunks.
• PCHG - Uses a PCHG (Palette Changes) chunk.

… und sie liefern sogar Beispieldateien. Gut, dass du mich erinnerst. Über das CRT-Gewusel hätte ich das jetzt fast vergessen. (Falls du Beispieldateien hast, immer her.)

[gdsWizard]

Leider kann ich Dir keine keine Beispieldateien geben, da ich nicht mehr viel vom Amiga aufgehoben habe. Das habe ich selber schon bereut.

[Krishty]

Aaaalso, ich habe mich an Sliced HAM und Dynamic HiRes versucht und wäre fast verzweifelt. Bis mir klar wurde, dass die Paletten von unten nach oben gespeichert werden. Was ich nie erwartet hätte, weil ich die Daten eh invertiert verarbeiten muss, um sie bottom-up in meinen Renderer zu schieben. Jetzt läuft es; also ab zum Aufräumen des Quelltextes.

An der Stelle Infos zur Notation:

1. Sliced Hold-and-Modify („SHAM“):
   • 5 oder 6 Bit Planes pro Pixel
   • werden als Hold-and-Modify dekodiert
   • wechseln ihre Palette
     • jede Zeile, falls nicht höher als 200 Pixel
     • jede zweite Zeile, falls nicht höher als 400 Pixel
     • können nicht höher als 400 Pixel existieren
   • Die Paletten kommen aus dem SHAM-Chunk
     • mit 2-B-Versionsnummer, die immer 0 ist
     • dann bis zu 200 Paletten in bottom-up-Reihenfolge, jede 16 Farben groß
     • jede Farbe als 0-R-G-B mit 4-4-4-4 Bits
   • Beispieldateien: http://cd.textfiles.com/fishandmore/Mor ... ures/Sham/
2. Dynamic HiRes:
   • von NewTek für ihr Videobearbeitungstool DigiView entwickelt
   • 4 Bit Planes pro Pixel
   • kein Hold-and-Modify o.Ä.
   • wechseln ihre Palette jede Zeile
   • keine Höhenbegrenzung (außer absurd hohe Werte wie 1024×768, mit denen sie warben)
   • die Paletten kommen aus dem CTBL-Chunk
     • exakt gleiches Layout wie SHAM, nur ohne 2-B-Versionsnummer am Anfang
   • Beispieldateien: http://aminet.net/search?query=demoreel
3. Dynamic Hold-and-Modify („DHAM“ oder „Dynamic HAM“):
   • 5 oder 6 Bit Planes pro Pixel
   • werden als Hold-and-Modify dekodiert
   • wechseln ihre Palette jede Zeile
   • wieder keine Höhenbegrenzung
   • die Paletten kommen aus dem CTBL-Chunk (siehe Dynamic HiRes)
   • Fun Fact:

     Since Dynamic modes must calculate a new palette for each scan line they take time to render. Low resolution Dynamic HAM takes about 2.5 minutes on a 512K Amiga.

That escalated quickly. Scheiße, mein Quelltext sieht jetzt aus wie die deutsch-französische Grenze vor 100 Jahren.

[Krishty]

VC 2015 CRT

Did I mention already that this is fucking retarded and annoying? Jesus christ fucking heads up your fucking asses.

It looks like I'll be stripping CRT use from Oodle Core. It's not that hard. We have our own sprintf, so I'll use that, and for logging I already take func pointers, so people can install stdio logging if they want, I just won't provide it by default.

(05-04-16 | VC 2015 CRT)

Willkommen im Club! Ihm ging es aber wohl um was anderes als mir:

04-20-16 | CRT

So VC 2015 has broken CRT link compatibility. (So). It was one of the ways that VC was better than the gcc/Linux nightmare (thought they've been trying really hard to fuck everything up in VC-land, what with SxS and winRT and so on). Apparently someone at VC said "hey you know how in Linux you can never share a binary build of a lib with other developers, because they used some different libc and it's a total nightmare? we should have that on Windows!" and everyone went "yeah! cool feature!". So now you can no longer share binaries in Linux or Windows.
The best solution, IMO, is to remove as much CRT use as possible. (for example, for VC 2015 you just have to remove all stdio use)

So you're taken the most basic shared library in C and made it unusable. Awesome.

[Krishty]

Aus der beliebten Serie „C ist ein Schrotthaufen“ heute die Episode „Ist eine Zahl ungerade?“ Mit Extra-Zusatz „StackOverflow ist voller Idioten“!

Also, ich habe ein int und davon weiß ich, dass es positiv ist. Ich muss wissen, ob es ungerade ist.

Schrott 1:

Ich kann das int nicht unsigned machen. Das würde nämlich eine Klasse vom Optimierungen verbieten:

If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X".

Die Frage, ob das int ungerade ist, ist auf StackOverflow relativ schnell und sicher beantwortet:

  if(x % 2)

Oder, weit abgeschlagen und abgewertet:

  if(x & 1)

if(x % 2) erzeugt mit Visual C++ folgenden Maschinentext:

  mov  eax,ecx
  and  eax,80000001h
  jge  013F48291Eh
  dec  eax
  or   eax,0FFFFFFFEh
  inc  eax
  test eax,eax

Warum? Weil der Compiler – mit Recht! – annimmt, dass die Zahl negativ sein könnte.

Schrott 2:

Ich sage dem Compiler, dass die Zahl positiv ist und nicht überlaufen kann:
  __assume(x >= 0 && x < 65536);
  if(x % 2)

… und die Befehlsfolge bleibt identisch. Jetzt macht Visual C++ das nicht mehr mit Recht.

Schrott 3:

Ich muss also von Hand schreiben

  if(x & 1)

und bekomme zumindest jetzt die sauber optimierte Version

  and  eax,1
  test al,al

Schrott 4:

… das auf StackOverflow war noch nicht zuende, oder? In der Antwort wurde der Quelltext nur für positive Zahlen getestet, und GCC hat das korrekt optimiert. Daher die Vermutung:

I also doubt any modern (made in the past 20 years) non-arcane compiler, commercial or open source, lacks such optimization.

Unlikely to matter - argument is a constant. Easy for the optimizer

most good optimizing compilers will generate exactly the same code for 'and 1' as for 'mod 2'.

I don't think it's fair to say it's faster than using division or modulus. The C standard doesn't say anything about performance of operators, and any decent compiler will produce fast code for either.

I believe that any modern C/C++ compiler will boil the "% 2" operation down to a bit test.

doubt, unlikely, think, believe – Es ist immer toll, solche Spekulationen hinzuschreiben, ohne sie zu testen.

Schrott 4.2:

Modern compilers will optimized x%2 to x&1 if/when such an optimization is both correct and faster. In old days, it was likely not to be correct (1's compliment systems), now a days, it's not likely to be faster (all arithmetic done in 1 cycle).

Mit Einerkomplement zu argumentieren und dann zu behaupten, ein Modulo wäre in einem Takt erledigt, ist so viel Idiotie, dass es extra Erwähnung verdient. (Ein Modulo dauert auf aktuellen CPUs 15 bis 80 Takte, abhängig von den Operanden.) Die „Aber der Code geht dann nicht auf Einerkomplement!“-Keule kommt noch gefühlte hundert Mal.

Schrott 5:

Fast niemand widerspricht diesem ganzen bei den Haaren herspekulierten Müll.

I tested with SDCC, and the bitwise version gives a LOT more compact and fast code.

(Ohne Reaktion.)

The version that uses bitwise and (&) is much more efficient than the modulo (%) version.

Reaktion:

bullshit :)

(25 Up Votes)

Schrott 6:

… was bedeutet, dass niemand anders es getestet hat (weder die tausend Up-Voter, noch die 215.000 Leser).

Schrott 7:

34 upvotes to explain modulo? No offense, but I feel like we've had plenty more tricky questions...and more elaborate answers.

Genau.

Schrott 8:

Die Leute fangen jetzt an, die zwar langsame, aber korrekte Antwort umzudeuten:

I agree with everything, except one thing: I like to keep integers and truth values separate, conceptually, so I prefer to write "if (x % 2 == 1)". It's the same to the compiler, but perhaps a bit clearer to humans. Plus you can use the same code in languages that don't interpret non-zero as true.

== 1, wirklich? Ob Division und Modulo in C auf- oder abrunden, bleibt der Implementierung überlassen. Für negative Zahlen ergibt x % 2 auf allen aktuellen CPUs -1. Glückwunsch, dein Code ist besser strukturiert, klar lesbar für Menschen, einfacher zu kopieren, und – vor allem – falsch!

Schrott 9:

Wieder: Niemand widerspricht!

Schrott 10:

Früher hätte ich da sofort hinschreiben können, dass das alles Idioten sind, aber jetzt soll ich dafür erstmal ein verficktes Benutzerkonto anlegen?! WTF?!

Da ist es doch effizienter, wenn ich hier ohne Registrierung schreiben kann, dass man auf StackOverflow nur Antworten auf schwierige Fragen trauen kann. Je banaler die Frage scheint, desto dümmer der Thread-Inhalt und desto schneller sollte man da weg.

Schrott 11:

Falls ihr es eben oben überlesen habt: „Ob Division und Modulo in C auf- oder abrunden, bleibt der Implementierung überlassen.“

[marcgfx]

hast wohl kein google konto? :)
finde es irgendwie schade, wenn du es den idioten nicht sagst, dass sie idioten sind.
aber ja, es tummeln sich verdammt viele leute dort. halbwissen reicht für die meisten antworten aus, eine schneller antwort ist den meisten lieber als eine absolut korrekte.
wer optimiert heute schon nocht, macht ja der compiler wie du schön zeigst viel besser :D

ich fand es auf alle fälle interessant, was du geschrieben hast. bin auch gar nicht erstaunt das module teuerer ist als eine bit-operation. lustig, dass so viele an den compiler gott glauben.

[Krishty]

Ja, und ich habe ebenfalls einen Brain Fart drin: Dass der Compiler das Modulo nicht durch AND ersetzt, liegt nicht an negativen Zahlen (denn für negative funktioniert das genau so). Sieht eher nach einer verpassten Peep Hole Optimization aus (Visual C++ will das Ergebnis der Modulo-Operation möglichst exakt annähern, ohne zu bedenken, dass am Ende nur Null oder nicht-Null entscheidend ist). Ich würd's gern mit ihrem neuen Optimizer testen, aber habe hier gerade zu kritische Dinge zu kompilieren um den zu installieren …

hast wohl kein google konto? :)

Boah geh mir wech. Ich hatte mehrere, aber wollte dort nie meine Telefonnummer eingeben. Außerdem habe ich sie mit Tor angesurft, was sie wohl als Angriff werten. Deshalb ist alles gesperrt und kann nur noch via Telefon (das ich nicht angegeben habe) freigeschaltet werden.

Ich sehe das nicht einmal als Fuck-Up, sondern eindeutig als Strategie, an meine Telefonnummer zu kommen. Da setze ich nie mehr einen Fuß rein.

[Tiles]

Huch, was hat denn Stack Overflow mit Google zu tun? Hab ich da was verpasst? O_O

[Krishty]

Man kann sich dort mit seinem Google-Konto einloggen. War Marcs Antwort darauf, dass ich mich erst registrieren muss :)

[Tiles]

Ah, jetzt. Ich dachte schon Google hätte auch das inzwischen eingemeindet :P

Nimm doch deinen Facebook Acc ... Na gut :D

[Jonathan]

Strawberry Perl (64-bit) cannot be installed in a directory with spaces or non-ASCII characters.

Vor 20 Jahren hätte ich das möglicherweise noch akzeptiert. Aber wer von denen denkt bitteschön, dass es heutzutage akzeptabel ist, wenn ich eine Software nicht im Standard-Pfad ("Program Files") installieren kann? Ich meine, ich sehe ein, dass wenn man viel mit der Kommandozeile arbeitet, Leerzeichen zu dusseligen Bugs führen können, aber das ist doch alles absolut vermeidbar. Ich habe ja bisher wenig mit Perl gemacht, aber soweit ich weiß, ist das irgendwie eine der Standard-Skriptsprachen, aber sie können trotzdem immer noch nicht mit Leerzeichen umgehen? Das finde ich jetzt schon ziemlich, ziemlich peinlich.

[Krishty]

UnsignedInt4B

<3 Explizität ftw

… und jetzt rücke ich davon ab, weil es zu viel Text ist. Insbesondere bei der Definition von Datenstrukturen hat man eine riesige Wall of Text, und das 1, 2, 4, oder 8 der Byte-Anzahl geht total unter. Wenn es sich dann noch spezialisiert (UnsignedInt4Bx4 für SIMD, UnsignedIntLeast4B für Registereffizienz, UnsignedInt4BLittleEndian für Dateidaten), ufert es völlig aus. Mal sehen, ob man mit UInt4B, UInt4Bx4, UIntLeast4B, und UInt4B_LE noch immer alles versteht.

P.S.: Schön, dass ich mich an vier Jahre alte Beiträge erinnere und sie in weniger als zehn Sekunden finde. Schade, dass ich nicht mehr weiß, worüber ich hier vorgestern gejammert habe.