Zitat von JohnFoo

Die zahlreichen Belege dafür wären mir unbekannt. Hättest du Beispiele? Das von LordNecro beschriebene Problem ist noch das komplexeste, das ich bisher gesehen habe.

Also ich hab mir jetzt auch mal das Kapitel aus der langspec durchgelesen, und es klingt tatsächlich alles recht naheliegend und unkompliziert. Nachdem ich mit Java aber typischerweise eher auf der Bytecode-Ebene zu tun hatte, weiß ich von dort, dass es schon einige Überraschungen im Zusammenhang mit protected gibt, z.B. http://dow.ngra.de/2008/11/03/when-protected-isnt-protected/

Das Verhalten der Vererbungen und Rechte ist in Java tatsächlich recht kompliziert und unüberschaubar. Ich habe das Gefühl, dass ein Großteil der Komplexität daher kommt, dass die Sichtbarkeit bzw. Nicht-Sichtbarkeit im Gegensatz zu C++ auch auf Binary-Ebene greifen muss. In C++ kann man ja locker mal in einem Headerfile etwas von private auf public umstellen und damit eine Object-Datei compilieren, die auf das private Feld zugreift; das ganze linkt man dann mit dem restlichen, normal compilierten Code zusammen und hat damit die Zugriffskontrolle ausgehebelt. In Java geht das einfach nicht.

Am hilfreichsten ist diesbezüglich wahrscheinlich, sich den Launcher von OpenJDK anzusehen. (Der Launcher ist das, was mit "java" aufgerufen wird). Ich hab in der Vergangenheit schon des öfteren mal den Code von OpenJDK konsultiert; der ist eigentlich üblicherweise recht übersichtlich.

Diese Fehlermeldung kommt übrigens, wenn das Manifest-File nicht passt. Das muss im gleichen Verzeichnis liegen wie die DLLs (wenn selbige nicht mit dem Installer, in diesem Fall also “Redistributable Runtime VS2005” oder so ähnlich, installiert wurden). Außerdem muss man bei der manuellen Installation händisch die Checksums aus dem Manifest rausnehmen, soweit ich mich erinnern kann.

Ist dir bewusst, dass MSVCR80.dll von Visual Studio 2005 ist? Du wirst wohl einen Build für VS2008 downloaden oder selber builden müssen.

Ich hab das 2008er vor ca. 1 1/5 Jahren von MSDNAA gesaugt und musste es auch 4 oder 5 mal anwerfen, bis es dann endlich mal komplett und ohne Checksum-Error da war. Wenn’s dann mal da ist, dann funktioniert es aber einwandfrei ;). Zum Glück wird eine Checksum geprüft, sonst wäre das bei dieser Zuverlässigkeit der Downloadserver wirklich zum Weinen.

Zitat von muckel

Also macht Java Schritt 3 nicht?

Nein. Wieso sollte es auch? Du hast ja hingeschrieben:

~x

und nicht

~x + 1

Zitat von michi204

also open reicht..

Stimmt...

Die C-Funktion heißt ftruncate. Wie das in perl heißt, musst du selber rausfinden :).

Alternativ kannst du auch /dev/null auf die Datei kopieren.

Tststs, nein so: so.

Also normalerweise macht man das per Perl-Skript irgendwann mal nach Monaten/Jahren :).

Das object in "synchronized(object)" muss natürlich das gleiche sein wie das, auf dem du dann .wait() und .notify() aufrufst.

Ja das hat sutupud eh geschrieben.

Zitat von Secretforce

Ich komme nicht weiter habe mir viele sachen zu Threads durchgelsen

Kann ich kaum glauben, aber bitte. Z.B. gibt's im Java Tutorial zu Threads diesen Abschnitt, der fast genau das macht, was du brauchst.

http://java.sun.com/docs/books/tut…/guardmeth.html

Generell gilt außerdem: wo wait() verwendet wird, braucht man eine while-Schleife

Du musst die Reihenfolge der Libraries ändern. Frühere können spätere nicht sehen, umgekehrt aber schon.

EDIT: Achso, hab mich verschaut. Eigentlich sollte es eh so passen. Aber mit der Reihenfolge herumspielen ist trotzdem oft nützlich

Deine Befürchtung ist korrekt ;). Wobei unter Windows Verzeichnis-Timestamps soundso nie hochgezählt werden, AFAIK.

Wenn deine Software ständig läuft, gäbe es noch die Möglichkeit, das Verzeichnis laufend zu überwachen - durch inotify o.Ä. (da gibt's so viele Varianten davon, dass ich aufgehört habe, darauf zu achten, welche gerade in Mode ist).

Zitat von Nicholas1991

Das komische ist. Trotz Double sind die Flächen z.T. um eine Pixelreihe verschoben.

Kennst du das hier ("What Every Computer Scientist Should Know About Floating-Point Arithmetic")? http://docs.sun.com/app/docs/doc/800-7895

Ich weiß, was du meinst. Das ist die Konsole von Win32, nicht DOS.

Du wiedersprichst dir mit dieser Aussage selbst. XP hat wohl eine DOS-Emulation eingebaut, aber die Konsole ist das nicht.