Klotzkopp

Die Header heißen <iostream>, <iomanip>, <cctype> und <cstdio>, wobei du die letzten drei gar nicht brauchst. Der cin-Aufruf kommt sowieso erst dann zurück, wenn der Benutzer die Eingabetaste drückt. Wenn das ganze nur den Zweck haben soll, dass der Benutzer nicht mehr als 100 Zeichen eingibt, dann benutz doch einfach einen std::string, dann hast du das Problem mit der Längenbeschränkung nicht mehr: #include <iostream> #include <string> using namespace std; int main () { cout<<"\t\tAutomatischer Rechner\n"; cout<<"\nGeben sie bitte Ihre Rechenkette ein:\n\t"; string line; getline( cin, line ); cout << line; } [/code] Dann brauchst du auch das nichtstandardisierte getch nicht mehr

Setz einfach das getchar in der Schleife hinter den if-Block.

\n, nicht /n Den Merker brauchst du nicht, weil du ihn ja sowieso sofort danach auswertest.

if (c == '\n')

http://forum.fachinformatiker.de/pruefungsaufgaben-loesungen/128200-berechnung-widerstaenden-reihenschaltung.html Meinst du nicht, dass es reicht, wenn du die Frage einmal stellst?

Da fehlen irgendwie ein paar Operatoren zwischen den Werten. Ich helfe lieber erst mal mit Denkanstoß: Welchen Gesamtwiderstand hat denn die Schaltung? Und wie ergibt sich der Gesamtwiderstand bei einer Reihenschaltung?

Ich weiß beim besten Willen nicht, wie du darauf kommst, dass Gunther irgendwelche Dateien von anderen Spielen verändern will. Nach allem, was hier steht, will er ein eigenes Spiel erstellen. Dazu bedient man sich üblicherweise (nicht zuletzt aus lizenzrechtlichen Gründen) nicht bei anderen Spielen.

Gunther will doch vermutlich eigene Modelle erstellen. Dann kann er doch gleich ein Freewareprogramm benutzen. Was soll er da mit einem Dateikonverter?

Erbt deine Klasse immer noch von acceptor? Falls das wirklich gewollt ist (was ich immer noch stark bezweifle), musst du in der Initialisierungsliste auch die Basisklasse initialisieren, denn die hat offensichtlich keinen Defaultkonstruktor.

Sie sollen natürlich keine sein, aber wenn du den Code unverändert aus einer Funktion in eine Klassendefinition verschiebst, dann wird daraus eine Methode. Dieselbe Zeile Code tcp::socket socket(io_service); bewirkt innerhalb einer Funktion die Deklaration eines socket-Objekts, an dessen Konstruktor das io_service-Objekt übergeben wird. Wenn dieser Code aber in einer Klassendefinion steht, deklariert er eine Methode namens socket (!), die einen (namenlosen) io_service-Parameter hat und ein tcp::socket-Objekt zurückgibt. Erschwerend (bezüglich des Verständnisses) kommt hier hinzu, dass du konsequent die Objekte genauso genannt hast wie die Klassen. Wenn das ein Objekt sein soll, dann muss die Initialisierung aus der Klassendefinition raus und in die Initialisierungsliste des Konstruktors. class create_serv_com : public tcp::acceptor { public: //... tcp::acceptor acceptor; tcp::socket socket; //...[/code] [code]create_serv_com::create_serv_com() : acceptor( io_service, tcp::endpoint(tcp::v4() , 13 )), socket(io_service) { // ... Und wie bereits gesagt, entweder ein acceptor-Member oder eine Vererbung. Beides gleichzeitig ist mit hoher Wahrscheinlichkeit Blödsinn. Außerdem rate ich dir dringend, die Variablen anders zu benennen. Die Fehlersuche wird nur unnötig schwerer, wenn ein Bezeichner sowohl ein Objekt als auch ein Typ sein kann.

und sind keine ausreichenden Fehlerbeschreibungen. Hast du irgendwo eine using-Direktive für den Namespace boost::asio? Dann sollte das io_service-Objekt vielleicht nicht gerade genauso heißen wie die Klasse. Das ist aber nur eine Vermutung. Für eine ordentliche Diagnose musst du eine ordentlich Fehlerbeschreibung abliefern.

Und welchen Sinn hat das SELECT, zu dem dieses FROM gehört, wenn du eigentlich Daten abspeichern willst? Du klatschst hier eine Abfrage- und eine Einfügeanweisung direkt hintereinander. Was soll das bewirken?

Warum schreibst du die gerade ausgelesene Zeile wieder in die Datei hinein? Was soll das fputs da? Und warum gibt fc_dateipfad das erste Zeichen des zusammengesetzen Pfades zurück, aber beim Aufruf wird mit dem Rückgabewert gar nichts gemacht?

Wenn das Einlesen funktioniert (das hast du hoffentlich mit dem Debugger geprüft), das Ausühren aber nicht, warum zeigst du dann den Code für's Einlesen, und nicht den für's Ausführen?

Du solltest den Pufferinhalt in die Datei schreiben, nicht den FILE-Zeiger der Quelldatei. Und wenn du immer nur ein einzelnes Byte liest und schreibst, brauchst du keinen Puffer von 100 Bytes.

Nein, genau so etwas habe ich erwartet. Und wenn du so kritische Dinge wie das Öffnen von Dateien im Code ordentlich behandelt hättest, hättest du vermutlich viel schneller gemerkt, wo das Problem ist. Die anderen Dinge, die ich angemerkt habe, solltest du übrigens auch umsetzen. Und sei es nur deshalb, damit sich dein Programm auch später noch übersetzen lässt, wenn du einen etwas aktuelleren Compiler verwendest.

Zeilenweise heißt Textdatei, Textdatei heißt CStdioFile. Und die Klasse hat eine ReadString-Methode.

Bei größeren Programmen ist das aber nicht empfehlenswert. Außerdem muss die main-Funktion den Rückgabetyp int haben. Zum eigentlichen Problem: Ich vermute, dass bereits das Öffnen der Datei fehlschlägt. Prüf doch mal den Status des Streams nach dem Öffnen und nach getline.

Auch mit Microsoft Visual C++ kannst du keine Allegro-Dialoge grafisch bearbeiten. Man könnte den Code nach WinAPI oder .NET portieren, aber das wäre ziemlich aufwändig. Ich glaube nicht, dass das jemand aus reiner Nächstenliebe macht, d.h. du wirst dafür bezahlen müssen. Warum nicht ein Dialogeditor für Allegro? Auf die Schnelle hab ich beispielsweise den hier gefunden.

Wer sagt denn, dass sie das soll? Selbst wenn das möglich wäre: Dadurch, dass man durch Structs beliebig neue Typen definieren kann, müsstest du eine unendlich große If-Kaskade bauen. Du könntest zusätzlich die Größe des Wertes übergeben, ein entsprechend großes char-Array bereitstellen und umkopieren. Dann müsste der Benutzer der Liste aber beim Zugriff auf die gespeicherten Elemente wieder in ein Objekt des passenden Typs umkopieren, weil nicht garantiert ist, dass ein char-Array für einen beliebigen anderen Typ passend ausgerichtet ist - Stichwort Alignment. Und selbst das klappt nicht, wenn die Elemente selbst Strukturen sind, die wiederum Zeiger auf Speicher enthalten, der wer weiß wo verwaltet wird. Was machst du denn, wenn bei der Typanalyse rauskommt, dass value ein Zeiger auf struct xyz { unsigned long* data_array; unsigned char* not_zero_terminated; struct xyz* next; };[/CODE] ist? In C kann eine generische Liste nicht den Speicher ihrer Elemente verwalten. Das bleibt Aufgabe des Benutzers.

Wie gesagt, in der Standardbibliothek gibt's keine Fenster. Windows Forms bedeutet, dass du .NET benutzt. Ich schieb dich mal ins richtige Forum.

Fenster gibt's im Standard nicht. Wenn du eine Bibliothek für grafische Benutzeroberflächen benutzt, solltest du verraten, welche

Man sollte sich das nicht als festen Bestandteil eines Programms angewöhnen, der ohne Hinterfragung angewendet wird. Namespaces dienen dazu, Bezeichner zu strukturieren und Namenskonflikte zu verhindern. Mit der using-Direktive hebelt man diese Wirkung wieder aus. Das ist nicht immer gewünscht. Ein using namespace std; mag besonders bei kurzen und einfachen Programmen sinnvoll sein, aber das ist nicht immer so.

Es gibt Regular Expressions für C++. Wenn dein Compiler den TR1 unterstützt, sogar eingebaut.