Klotzkopp

@nic_power: IIRC lässt scanf den int unverändert, wenn es keine Zahlen zum Umwandeln findet. Kannst du ein Beispiel bringen, das abstürzt?

Dieser Code allein sollte noch keinen Absturz verursachen. Ich denke, es liegt eher daran, was du danach mit den Daten machst.

Stimmt, weiß auch nicht, wie ich darauf gekommen bin. Ich hatte irgendwie in Erinnerung, dass recv blockt, bis der Puffer voll ist. War wohl nun ein Traum...

Ja.

Es gibt keine 1-zu-1-Beziehung zwischen send und recv, das sind reine Byteströme. Dein recv wird AFAIK erst dann zurückkommen, wenn die 501 Bytes voll sind. Natürlich können dann mehrere Strings drinstehen. Und der letzte String im Puffer ist mit ziemlicher Sicherheit nicht vollständig.

Ja. Weil l und r die Positionen von zwei Zahlen sind, die vertauscht werden müssen. Wieso sie das sind, ergibt sich aus den beiden while-Schleifen davor. l und r laufen aufeinander zu. Dabei bleibt l stehen, wenn der Wert an der Position l nicht kleiner als das Vergleichselement ist, und r bleibt stehen, wenn der Wert an der Position r nicht größer als das Vergleichselement ist. Daher gilt nach den while-Schleifen: A[l] >= Vergleichswert >= A[r]. Darum wird getauscht. Naja, nachdem sich l und r begegnet sind, sind wir ja noch nicht fertig. Wir wissen nur, alles was links von l steht, ist kleiner als der Vergleichswert, und alles was rechts von r steht, ist größer als der Vergleichswert. Also werden beide Unterbereiche nochmal sortiert. Das geht üblicherweise solange, bis die Bereiche so klein geworden sind, dass die Sortierung trivial wird (2 Werte oder weniger).

Die Frage ist: was machst du nach dem recv? Berücksichtigst du, dass mehr als ein nullterminierter String in dem Puffer stehen kann?

Dann machst du selbst beim Empfangen oder Senden etwas falsch. Die eingebaute Fehlerkorrektur bei TCP sorgt dafür, dass nichts verloren geht und die Reihenfolge stimmt. Da es relativ schwierig ist, beim Senden etwas falsch zu machen , tippe ich mal darauf, dass beim Emfang was nicht stimmt.

Hier werden nicht die Werte verglichen. r und l sind die aktuellen "Suchpositionen". Die beiden Schleifen, die dieser Abfrage jeweils vorausgehen, stellen sicher, dass diese Positionen auf Werten stehen, die ausgetauscht werden müssen (weil diese beiden Schleifen nach genau solchen Werten suchen). Der Austausch darf aber nur gemacht werden, wenn l und r nicht inzwischen "aneinander vorbei gelaufen sind". Daher vorher der Test auf l < r.

Verwendest du TCP (SOCK_STREAM) oder UDP (SOCK_DATAGRAM)?

Nein, mit dem Falcon.

Das ist einer von den dreien, die das können, ja. Den Eagle bekommst du auf Freeport 9, Omicron Theta. Hoffe, du verstehst dich gut mit den Zoners.

Price: $ 558,550 Gun/Turret Mounts: 6/1 Armor: 9900 Cargo Space: 70 Max. Batteries/Nanobots: 63 Optimal Power Rating: 8 Max. Power Rating: 10 Add. Equipment Slots: M, CM, CD/T Geht mir genauso. Raketen und Minen sind mir für den IHMO geringen Nutzen zu teuer. Dromedary (275): Mactan Base.

CDocument::OnFileSaveAs ist MFC2.0 (also 16 Bit). Bist du wirklich sicher, dass du damit arbeitest? Falls nicht, würde ich dir raten, CDocument::OnSaveDocument zu überschreiben, da bekommst du den Dateinamen als Parameter mitgeliefert.

Entweder suchst du jemanden, den du bestechen kannst, um dein Ansehen bei den Corsairs zu steigern, oder legst dich mit ihren Feinden an. Und das sind nicht wenige: Red Hessians, GMG, Outcasts, Mollys, alle Polizei- und Militärgruppierungen. Wobei du es dir mit den Outcasts auch nicht verscherzen solltest, die haben auch ganz gute Ausrüstung. Allerdings solltest du nicht zu sehr auf deinen Ruf achten, solange du die Einzelspielermissionen nicht durchgespielt hast, denn die bringen deinen Ruf manchmal ziemlich durcheinander. Klotzkopp, stolzer Besitzer eines 'Eagle' und derzeit Freelancer-süchtig P.S.: Der 'Titan' fliegt sich wie ein Ziegelstein.

Für die Berufsverteilung haben wir schon eine Umfrage: http://fachinformatiker-world.de/forums/showthread.php?s=&threadid=31103&werbeid=13

Eigentlich sollte das mit CDocTemplate::CreateNewDocument gehen. Du kannst ja mal in diesen Thread schauen, da ging es um ein ähnliches Thema.

Kann sein, dass ich das jetzt falsch verstehe, aber das, was du beschreibst, nenne ich "Algorithmik". Oder wie würdest du es nennen?

Wobei ich finde, dass ein solcher Beweis ohne eine exakte Definition von "Weiß", "Schwarz" und "Farbe", losgelöst von menschlichen Sinnesempfindungen und Sprache, nicht möglich ist. Und diese Definitionen sind IMHO nicht so einfach. Das ganze lässt sich wohl nur philosophisch beantworten. Aber auf diesem Gebiet sind Beweise ja auch eher selten.

Wie ist HideTimerProc deklariert?

Hab noch ein paar: *giebt (108) (*, damit auch 'ergiebt' mitgezählt wird ) währe (426) bischen (1056) Und ich hab meine Sig wiedergefunden...

Auch nicht schlecht: blos (230) Ich hatte da mal eine Sig... Nachtrag: Ich denke, das ist nicht mehr zu toppen: - vorraus (1456) - vieleicht (1291)

Richtig. Ich sagte ja auch nur "z.B." Normalerweise würde man den Zeiger als Member einer anderen Klasse deklarieren, so dass man später auch noch auf den Dialog zugreifen kann, und ihn, wenn man ihn nicht mehr braucht, freigeben kann.

Nein, das wird nicht funktionieren, weil außer dir niemand das Bild auf der Platte hat. Du wirst es schon auf einen Webserver hochladen müssen. Oder schicke es mir, dann kann ich es an einen Beitrag anhängen. Wobei genau? Was klappt nicht?

vector<bool> ist in allen mir bekannten Implementierungen eine template-Spezialisierung, die die Elemente nicht als bool-Array, sondern als Bitfeld speichert. Aber inzwischen denke ich, dass es doch gehen müsste. Es kommt auch nicht darauf an, wie die vector-Klasse implementiert ist. Solange es ein Random-Access-Iterator ist, sollte das mit dem begin() funktionieren.