So lange für ein File (oder ein Projekt) konsistent Tabs oder Spaces verwendet werden, ist es fast egal, was du machst. Aber wenn mehrere Leute mit unterschiedlichen Einstellungen an einem File arbeiten, dann wird's echt schlimm...
Für vim empfehle ich:
set shiftwidth=4
set ts=4
set expandtabUnd für Emacs:
indent-tabs-mode: nil
tab-width: 4+ bedeutet, dass das, was vorher steht, einmal oder öfter vorkommen muss.
Das i bedeutet "ignore case".
Das $ bedeutet "Ende der Zeile/des Strings"
Du kannst die Critical Section nicht einfach so zerstören, nachdem du sie verwendet hast. Die soll üblicherweise beim Programmstart oder sonst irgendeiner Initialisierung erzeugt und erst ganz am Schluss, wenn sie garantiert nicht mehr in Verwendung ist, zerstört werden – natürlich kann man in den meisten Fällen auch einfach so das Programm beenden. Das sind ja nur ein paar Werte im Speicher…
Jedenfalls ist die Grundidee, dass alle Threads, die einander ausschließen sollen, dieselbe Critical Section verwenden. Wenn jeder seine eigene verwendet (was du durch das Ständige Erzeugen und Zerstören hättest), dann bringt das gar nix.
Die meisten (alle?) Schriften enthalten nur eine Teilmenge aller Zeichen. Ich habe keine Ahnung, wie Java das macht, aber soweit ich weiß, gibt es verschiedene Layoutlibraries (z.B. pango), die sich auf magische Weise die Zeichen aus verschiedenen Schriften zusammenklauben.
Sprichst du hier von der Ausgabe auf der Konsole oder von einer GUI-Anwendung?
"Benennst" du das wirklich nur um (im gleichen Verzeichnis)? Oder verschiebst du es z.B. auf eine andere Partition?
Kann es sein, dass du Java herunterfährst oder den Thread irgendwie killst, während das Ding läuft?
Ist die Platte (fast) voll? Überschreitest du deine Quota?
Kommt mir zwar alles komisch vor, aber irgendeinen Grund wird's schon haben...
Ok ich hab mich wohl nicht klar ausgedrückt. delete statt delete[] zu verwenden hat "meistens" zur Folge, dass Destruktoren nicht aufgerufen werden. Jedenfalls hast du recht.
Weil das halt komplett unterschiedliche Dinge sind.
malloc/free sind Funktionen der C Runtime Library.
new/delete/delete[] sind Keywords von C++ bzw. Funktionen der C++ Runtime Library.
Die müssen miteinander überhaupt nichts zu tun haben. Außerdem kann man die operatoren new/delete sowohl global als auch pro Klasse durch eigene Funktionen ersetzen. Und Destruktoren sollen auch noch aufgerufen werden — auch das geht nur mit delete (bzw. meistens delete[]).
Nein, darfst du nicht. Leider funktioniert es mit vielen Compilern oder besser gesagt mit den mitgelieferten Runtime Libraries und fällt daher nicht so bald auf, aber grundsätzlich ist es "undefined behaviour".
Bei Advanced Compiler gibt’s rechts oben “Autodependency information”. Zumindest beim BCB 6. War aber beim 5er auch nicht anders, glaub ich. Aber ich hab ihn nicht mehr 
Ja, musst du.
Das ist aber nicht normal. Eigentlich sollte er das rebuilden, was nötig ist, wenn du F9 drückst. Tut er üblicherweise auch (hab selber lang genug damit gearbeitet). Mit zunehmender Projektgröße wird dieser Check, was er neu builden soll, zwar furchtbar langsam, aber sonst hatte ich damit eigentlich kaum Probleme. Hast du vielleicht bei den Compileroptionen die Dependency Generation abgedreht? Irgendsowas gibt's da, glaub ich.
Ganz einfach, Datenbanktransaktionen sollen immer so verwendet werden:
1. Transaktion starten
2. Daten ändern (oder lesen)
3. Commit (oder rollback)
Und zwar so schnell wie möglich hintereinander.
Du hast dich nicht daran gehalten (dein Commandline-Client hatte ne Transaktion offen), daher hast du Probleme bekommen.
Ja das muss jeder mal lernen ;). Datenbanktransaktionen sind einfach nicht dafür gedacht, lange offen zu bleiben.
Also zumindest bei MySQL/InnoDB kann man die Effekte, die a9bejo meint, ziemlich gut beobachten. Aber es kann schon sein, dass sich Oracle anders/"besser" verhält.
Sind das lauter String-Spalten?
Eher systray oder "System Tray".
1. Überleg dir einen geschlossenen Ausdruck für t(i) - also den Wert t in der i-ten Iteration.
2. Wenn eine einzige Schleife n-mal durchlaufen wird, ist es trivialerweise O(n)
3. Das sollte eigentlich klar sein, wenn du weißt, was ein Logarithmus ist.
z.B.
4>n<=8, Schleife 3mal
8>n<=16, Schleife 4mal
16>n<=32, Schleife 5mal
usw.
Da musst du dir wohl den erzeugten Assemblercode im Detail ansehen. Wenn du mit verschiedenen Compilern/Compileroptionen/CPUs herumspielst, wirst du wohl es wohl recht bald schaffen, dass jede der drei Varianten mit irgendeiner Kombination die schnellste ist.
Dauert es also länger wenn ich auf ein Double Word im Cache zugreife, als auf ein Word?
Nein.
Nun kann ich ja davon ausgehen, dass bei kleinerer Blockgröße der Cache weniger nachgeladen werden muss. Angenommen das Nachladen kostet eine gewisse Zeit t. Meinst du damit, dass für eine kleinere Blockgröße das Nachladen im einzelnen weniger Zeit brauch?
Nein. Die Zeit für das Nachladen von einer Cacheline ist relativ konstant. Aber je größer deine Datenelemente sind, umso weniger davon passen halt in eine Cacheline hinein.