Wenn's schneller wäre, dann würde es ja wohl gemacht werden. Es gibt aber keine einzige große JVM, die es tut. Genausowenig macht es .NET.

Reference counting ist langsamer, das ist alles.

1. File System Check (hast wahrscheinlich eh schon gemacht)
2. rpm -V für jedes installierte Paket (Liste kriegst mit rpm -qa)

Die Ausgabe vom rpm -V musst du dann schon händisch durchschauen, aber allzuviel Arbeit ist das nicht. "Interessant" wären Files, bei denen sich die MD5 sum geändert hat (5)

Es klingt wirklich so, als ob du irgendwas wichtiges bei der .config vergessen hättest. Probier's mal damit: (Hardware musst du halt ein bisschen anpassen)

http://www.visotech.at/~sr/.config

Richtig, solange sich der allozierte Speicher in Grenzen hält, ist das sehr brauchbar. Für große Speichermengen empfiehlt sich halt dann doch ein größerer Addressraum, sprich 64 Bit-Maschinen.

Btw, der Boehm GC wird z.B. von GCJ (GNU Java Compiler), GNU Objective C, Mozilla und Mono verwendet und funktioniert dort offenbar ausgezeichnet.

Du, ich weiß, was eine Java VM macht, ich arbeite nämlich an einer im Rahmen meiner Diplomarbeit. Und der Boehm GC, ein sehr weit verbreiteter Garbage Collector, tut genau das, was ich beschrieben habe, nämlich den Speicher scannen. Außerdem haben die Pointer auf einer 32bit-Maschine natürlich 32 Bit und nicht 64.

Kann schon vorkommen, dass der GC was überlässt, was eigentlich gelöscht werden sollte. Kommt einfach drauf an, wie er den Memory scannt. Wenn er einfach alle 32 bit-Worte liest und als Pointer betrachtet, kann's ja schon mal zufällig passieren, dass ein solcher in einen Speicherbereich reinzeigt, der alloziert ist. V.a. wenn das Programm ein paar hundert MB braucht, ist das leicht möglich. Auf 64 bit-Maschinen passiert's klarerweise viel seltener, weil da schon einiges an Glück dazugehört, um mit einem wild zusammengewürfelten Pointer genau einen gültigen Speicherbereich zu treffen.

Auch wenn du es hinbekommen würdest, würde es wahrscheinlich nicht funktionieren. Viel besser geht's mit dem eingebauten X forwarding von ssh (-X)

Du kannst kein gif includen, sondern nur eps.

Ich glaub bei Borland gibt der Linker nur eine Warning, wenn was doppelt definiert ist. Und selbst die kann man ausschalten (-wdup bzw. -wdpl)

Das ist kein Stil, das ist ein Zustand!

Also jedenfalls funktioniert der Borland C++ Compiler genauso wie jeder andere auch. Du machst nur unterschiedliche Dinge in den beiden. BC hast du wahrscheinlich so verwendet: bcc32 main.cpp. Wie du oben gesehen hast, geht das mit VC++ auch. VC++ verwendest du hingegen von der IDE aus, wo du alle .cpp Files in ein Projekt gegeben hast. Daher werden alle übersetzt und am Ende zusammengelinkt -> Fehler. Würdest du das mit dem BC machen, würde er sich genauso beschweren. Wenn du es also weiterhin mit VC++ in der IDE compilieren willst, dann nimm alle .cpp Files bis auf das main.cpp aus dem Projekt raus, dann müsste es gehen.

Wieso es mit deiner Methode nicht geht, haben wir jetzt schon dreimal geschrieben. Weil du mehrere Object-Files zusammenlinkst, deren Methoden sich teilweise überschneiden.

Deine #include-Struktur ist völlig schwachsinnig, sorry bitte es ist wirklich so.

Jedes .cpp File soll "sein" .h File inkludieren. Optional noch andere .h Files dazu.
Jedes .h File kann optional andere .h Files inkludieren.
Jedes .h File soll Include Guards haben (das hast du eh)
Ein .h File darf NIE ein .cpp File inkludieren.

Wie du hier siehst, geht es problemlos.

E:\Documents and Settings\Administrator\Desktop\test>cl /GX main.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

main.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:main.exe
main.obj

E:\Documents and Settings\Administrator\Desktop\test>main
9
8
E:\Documents and Settings\Administrator\Desktop\test>

Chris: Kreativ - und wahrscheinlich besser, als man es je mit einer auf Annahmen basierenden Nachprogrammierung von NTFS erreichen würde. Ich wollte es schon seit Wochen ausprobieren, hoffentlich komm ich bald mal dazu.

Wenn du in zwei Übersetzungseinheiten eine Variable (oder Funktion) mit dem gleichen Namen anlegst und sie nicht extern oder static deklarierst, dann kollidieren die beiden beim Linken. So ist das nun mal in C.

Wenn du nun ein .cpp File inkludierst, werden alle Variablen, die darin angelegt werden, auch in der inkludierenden Übersetzungseinheit angelegt -> Clash.

Was das Inkludieren von .cpp Files betrifft, verhalten sich eigentlich alle Compiler gleich (eine Ausnahme ist vielleicht Visual Age von IBM, aber das gibt's glaub ich schon lang nicht mehr). Wenn du mit VC++ auch nur das eine File ins Projekt geben würdest, das du mit dem BCC compilierst, dann würde auch das gleiche rauskommen. Umgekehrt würde sich der Borland Linker auch beschweren, wenn du jedes .cpp File compilieren würdest und danach alles zusammenlinken wolltest.

Wenn du die .cpp Files inkludierst, kannst du auch nicht erwarten, ohne Probleme davonzukommen. Deklarationen nach .h, Code (außer Template-/Inline-Code) nach .cpp.

Den Stick mit FAT zu formatieren bedeutet normalerweise seinen sofortigen Tod (wie's mit NTFS ausschaut, weiß ich nicht).

http://developers.slashdot.org/article.pl?sid…=thread&tid=137

Ein BSTR ist kein Stream, sondern ein String. Deren Behandlung wird in der MSDN Library ausführlich beschrieben.

Eine Möglichkeit wäre, mit 1000 zu multiplizieren und dann Math.round zu verwenden. Du musst allerdings bedenken, dass du dabei nicht den Wertebereich von double verlassen darfst (2^63)