Klotzkopp

Das klingt für mich danach, als würdest du Echtzeitspiele bevorzugen. Dragon Age Origins wirst du (außer vielleicht auf der einfachsten Schwierigkeitsstufe) nicht in Echtzeit durchspielen können. Bei diesem Spiel kann man jederzeit zwischendurch anhalten, um die Taktik anzupassen, und das muss man oft auch. Was das Blut angeht, wirst du allerdings auf deine Kosten kommen.

Ich schlage vor, dass wir uns auf folgendes einigen: Es ist egal, welchen Logarithmus man hier verwendet. Der dekadische ist anscheinend laut Aufgabenstellung vorgegeben. Sowohl Zinsfaktor als auch Start- und Endkapital sollten positiv rational sein. Wir warten jetzt mal ab, ob der Threadersteller sich nochmal meldet.

Es wäre wohl hilfreich, wenn du im Klartext beschreibst, wie dein Algorithmus arbeitet. Es gibt hier vermutlich etliche Leute, die deinen Algorithmus bewerten können, aber nur ein kleiner Teil davon dürfte Logo gut genug kennen, um das aus dem Code herzuleiten. Zudem wissen wir nicht, was die einzelnen Pixelfarben bedeuten. Ist das Labyrinth schwarz auf weiß oder rot auf blau oder ganz anders?

Ich will ja nicht unken, aber meiner Meinung nach kann man mit einer durchschnittlichen Datenreduktion gar keinen maximalen Speicherbereich berechnen. Dazu würde man schon eine schlechtestmögliche Datenreduktion brauchen. Aber wenn man das beiseite lässt: Ermittle, welches der drei Aufnahmeformate das größte ist. Von diesem rechnest du dann die Anzahl der Pixel aus. Die Auflösung in Pixel pro Zoll hast du ja, und der Umrechnungsfaktor von Zoll zu Zentimeter steht auch da. Dann multiplizierst du die Anzahl der Pixel mit der Farbtiefe, rechnest das in Kilobyte um, und wendest dann darauf die Datenreduktion an.

Da Inhalt eine innere Klasse von Buch ist, kannst du keine Inhalt-Instanz ohne eine Buch-Instanz anlegen: Buch b = new Buch(); Buch.Inhalt i = b.new Inhalt(); [/code] Was ich mich aber frage: Wozu haben deine Methoden Parameter? Parameter sind Eingabewerte für Methoden, aber deine Methoden tun gar nichts mit ihren Parametern, sie überschreiben sie sofort. Anstatt den Parameter einzulesen und dann dem Instanzattribut zuzuweisen, könntest du auch gleich das Instanzattribut selbst einlesen. Dann könntest du die Parameter komplett weglassen.

Pipes (Windows) Wie, IPC? IPC ist der Überbegriff für alle Mechanismen zum Datenaustasch zwischen Prozessen. Pipes sind einer davon. Für den Client: FTP Sessions (Windows) Falls du auch den Server implementieren musst, ist das vier bis fünf Nummern zu groß für dich. Diese Aufgabenstellung passt so überhaupt nicht zu deinem Kenntnisstand. Der Aufgabensteller hat anscheinend eine andere Vorstellung davon, was du können solltest, warum, kann ich nicht beurteilen. Mit C++ hat das aber ohnehin nicht viel zu tun, falls du, wie ich vermute, das Windows-API benutzen sollst, denn das ist ein reines C-API.

Und bei welchem Teil kommst du nicht weiter? So eine Aufgabe bekommt man ja nicht, wenn man keine Vorbildung hat (oder haben sollte). Und geht's um Windows-Pipes oder POSIX-Pipes?

Verschoben -> .NET

Ist denn der mathematische Teil klar? Weißt du, wie man aus den gegebenen Daten die Anlagedauer berechnet?

Wenn du sie nicht fängst, wird die Exception den Thread beenden, nicht anhalten. Das hängt ja nun davon ab, was du in dem catch tust. Aber das hast du ja offenbar schon selbst gemerkt.

Wenn in einem anderen Thread eine Exception fliegt, ist es normal, dass die anderen Threads weiterlaufen. Oder meinst du in diesem Thread? Ich verstehe nur Bahnhof. Was meinst du mit "ausreichen"? Ich verstehe immer noch nicht, was du vorhast. Was willst du mit der Information, die dir dieses Property liefert.

Ja, aber zu welchem Zweck? Was gedenkst du mit dieser Information zu machen?

Verschoben -> .NET, Threadtitel angepasst. Hier steht, dass die Threadstates nur für wenige Debuggingszenarios sinnvoll sind. Was willst du denn damit überhaupt erreichen?

Das ist etwas problematisch, und zwar aus zweierlei Gründen: Erstens lernst du dabei nicht, wie du solche Probleme selbst löst. Du kommst also mit hoher Wahrscheinlichkeit mit den nächsten Aufgaben auch wieder vorbei und möchtest, dass jemand sie für dich löst. Das ist auf Dauer weder für dich noch für uns günstig. Und zweitens ist das, was du möchtest, eigentlich genau das, wofür die Leute hier im Forum üblicherweise bezahlt werden (oder später einmal bezahlt werden wollen): Die Arbeit für andere erledigen, die es nicht selbst können oder wollen. Wir sind gern dazu bereit, dir beim Lernen zu helfen, aber wir machen hier nicht deine Arbeit. Setz dich dran, mach dir ein paar Gedanken, zeig, was dabei rausgekommen ist, und sag, an welchen konkreten Stellen du nicht weiterkommst, dann wirst du hier kompetente Hilfe finden. Aber ohne Anzeichen von Eigeninitiative wird das nichts. Hinweise zur Vorgehensweise hast du ja schon bekommen.

Grafische Benutzeroberflächen sind nicht Teil des C++-Standards, das ist der Teil, der überall einheitlich ist. Es gibt natürlich diverse Bibliotheken für grafische Benutzeroberflächen, manche nur für bestimmte Betriebssysteme, manche für mehrere. Wie man damit umgeht, hängt stark von der verwendeten Bibliothek ab. Allgemeine Informationen wirst du dazu also kaum finden. Du kannst dir jetzt ein MFC-Tutorial ansehen, aber davon hast du nicht viel, wenn du später Qt verwenden sollst. Diesbezüglich solltest du vielleicht zunächst abwarten, welche Bibliothek in deiner Umschulung verwendet wird.

Und weil dir kein ordentlicher Titel für einen Thread eingefallen ist, hast du dich an einen anderen Thread drangehängt, dessen Ersteller dasselbe Problem hatte? Wir können hier natürlich in jedem Unterforum einen "Hilfe"-Thread aufmachen, in dem einfach jeder sein Problem hinten dranhängt. Dann könnten wir alle anderen Threads ja zumachen. Machen wir aber nicht. Ich trenne deinen Beitrag ab und denke mir einen passenden Threadtitel aus. Letzteres machst du beim nächsten Problem bitte selbst Interessant. Ist auch irgendwas gesucht? Denn ansonsten wird das ein ziemlich einfaches Programm. So wie jedes andere Programm auch. Man überlegt sich, was die Eingabedaten sind, wie sie verarbeitet werden müssen, und was die Ausgabedaten sind. Man könnte auch ein Struktogramm oder einen PAP erstellen, um den Algorithmus zu klären. Wo genau ist denn dein Problem bei dieser Aufgabenstellung? Du erwartest doch hoffentlich nicht, dass dir hier jemand eine Komplettlösung auftischt?

Man verteilt den Code auf Übersetzungseinheiten. Jede Übersetzungseinheit (ÜE) wird vom Compiler einzeln bearbeitet. Am Ende verbindet der Linker alles zu einem ausführbaren Programm. Eine ÜE ist eine .cpp-Datei. Wenn du in einer Datei Funktionen aus einer anderen brauchst, brauchst du nicht den vollständigen Code, sondern nur die Deklaration der Funktion. Die sieht in deinem Fall so aus: float RechteckFlaeche(float wert1, float wert2, int koerperWahl); In C nennt man das auch einen Prototypen. Das ist alles, was du brauchst, um in einer anderen .cpp-Datei diese Funktion nutzen zu können. Und damit man das nicht immer wieder hinschreiben muss, benutzt man sogenannte Headerdateien (Dateierweiterung .h). In denen stehen nur die Deklarationen der Funktionen (also kein Code). Diese Dateien kann man dann auch in mehreren .cpp-Dateien einbinden, ohne dass der Linker auf Probleme stößt. Das Konstrukt aus #ifndef/#define/#endif sind die sogenannten Include-Guards. Jede Headerdatei sollte so etwas haben. Das hat den Zweck, dass die mehrfache Einbindung dieser Headerdatei in dieselbe ÜE keine nachteilige Wirkung hat. Das kann schon mal passieren, wenn Header andere Header einbinden. Das Symbol FUNCTION_RECHNEN_H_INCLUDED muss keinen bestimmten Namen haben, es sollte nur für das Projekt eindeutig sein. Die Verwendung von Großbuchstaben ist auch kein Zwang, aber allgemein üblich. Diese Datei nennst du dann function_rechnen.h. Diese Datei kannst du dann in main.cpp mittels #include einbinden. Außerdem musst du natürlich die Datei function_rechnen.cpp dem Projekt hinzufügen, damit der Compiler sie auch bearbeitet.

So etwas tut man nicht. Wenn du etwas auslagern willst, solltest du eine Headerdatei anlegen, die die Deklarationen (und sonst nichts) für die ausgelagerten Teile enthält, und diese einbinden. Was du da machst, funktioniert nur für ganz einfache Fälle. Es gibt es mehrere IDEs, die MinGW als Compiler benutzen können. Welche benutzt du denn? Doch hoffentlich nicht Dev-C++? Davon lass besser die Finger. Die Direktive, die du suchst, heißt #include, nicht #ifdef. Außerdem solltest du den Dateinamen in spitze Klammern oder Anführungszeichen setzen. Aber wie gesagt, eigentlich solltest du andere Quellcodedateien gar nicht so einbinden.

Hast du denn für deine Klasse die equals-Methode überschrieben? Denn ansonsten kommt Object.equals zum Einsatz, und das vergleicht tatsächlich nur, ob die Objektverweise identisch sind.

Ja, dieselbe Frage würde ich wohl auch stellen. Wir können jetzt natürlich raten, welches Betriebssystem, welche Bluetooth-Hardware, welche Treiberversion und welche sonstige Software du so installiert hast. Aber einfacher ist es sicher, wenn du diese Informationen einfach mal angibst.

Laut Standard ist das ein unvollständiger Typ. Viele Compiler bieten allerdings eine Erweiterung, die diese Deklaration als Array der Größe 0 interpretieren, wenn es Member eine Klasse oder Struktur ist. Das sollte aber eigentlich nur dann funktionieren, wenn dieses Array der letzte Member ist. Wie auch immer, diese Deklaration bedeutet nicht, dass du hier ein dynamisches Array hast, das sich bei Bedarf selbst anlegt oder gar automatisch vergrößert. Das musst du entweder von Hand machen, oder einen geeigneten Container benutzen.

Die Bedeutung von "das Rad neu erfinden", ist üblicherweise die, dass man nicht eine existierende Bibliothek verwendet, sondern eben alles selbst neu implementiert. Dein ersten Ziele sollte Funktionsfähigkeit und ein sauberes Design sein, für Effizienzmaximierung ist es noch etwas früh. Ein Chat hat relativ geringe Bandbreitenanforderungen, wenn du nicht gerade ein Dateiaustausch-Feature einbaust. Mach's einfach mal so, wie du es dir überlegt hast, das ist kein schlechter Ansatz.

Das ist kein Problem, sondern ein völlig normales Verhalten. Du hast einen Stream-Socket erstellt (SOCK_STREAM), also hast du einen Strom von Bytes zwischen den Endpunkten. Es gibt da keine Markierungen, wo ein send-Aufruf endete und der nächste anfing. Diese Information wird einfach nicht übermittelt. Es kann übrigens auch passieren, dass dir ein recv-Aufruf weniger Daten liefert, als beim send abgeschickt wurden, und du dir die Daten mit wiederholten recv-Aufrufen zusammenstückeln musst, bis du alles hast, was du brauchst. Wenn der das Empfänger nicht anhand der empfangenen Bytes erkennen kann (feste Größe der Nachricht?), dann musst du so etwas wohl tun. Denk dir ein "Endezeichen" aus, das sonst so in deinem Datenstrom nicht vorkommen kann. Was gesendet wird, hast du doch selbst in der Hand.

Diablos' Schaden ist proportional zu seinem Level.

Hier gibt's eine Anleitung: Steps in a Typical HTTP Client Application