Klotzkopp

Du brauchst eine Variable für den größten bisher eingebenen Wert, und eine für den kleinsten. Nach jeder Eingabe vergleichst du die mit dem gerade eingegebenen Wert und aktualisierst gegebenfalls die Variablen. Und nebenbei: <iostream.h> ist seit fast 11 Jahren falsch. <iostream> heißt das, ohne .h.

Ein mehrseitiges PDF klingt nicht gerade nach einer Anfängeraufgabe. Woher kommt diese Diskrepanz? Werden da zu schwere Aufgaben verteilt, oder solltest du eigentlich kein Anfänger mehr sein? Und ob du das hier veröffentlichen darfst, kann dir nur der Urheber sagen. Wenn in dem Dokument selbst nichts dazu steht, kannst du nicht davon ausgehen, dass du es hier vervielfältigen darfst.

Du könntest die Aufgabenstellung verraten.

Die Anzahl der Fehler ist weniger interessant als der Inhalt der Fehlermeldungen Das sieht wie ein Mittelding zwischen Funktionsdeklaration und Funktionsaufruf aus. Was soll's denn sein? Kann es sein, dass du einfach Code von irgendwoher zusammenkopiert hast, ohne ihn zu verstehen? Das funktioniert selten.

Anderes Problem desselben Users abgetrennt, hier geht's weiter.

Dann mach dafür bitte einen neuen Thread auf. Das Board ist themenzentriert, nicht benutzerzentriert. Dein neues Problem hat nichts mehr mit "undefined reference" zu tun, also sollte es auch nicht in einem Thread mit diesem Titel behandelt werden. Ich habe das mal für dich abgetrennt. Du hast zwei Vectoren. In den einen schreibst du die Werte rein, aus dem anderen versuchst du dann, die Anzahl auszulesen. Das klappt natürlich nicht. Ganz allgemein zur Objektorientierung: Mit Klassen modelliert man in aller Regel Objekte, nicht Tätigkeiten. Eine Klasse mit der Beschreibung "vector füllen" oder "vector auslesen" klingt komisch. Wenn du einen Konstruktor anlegst, der dann aber nichts tut, kannst du ihn dir auch sparen. Der Compiler generiert dann automatisch einen für dich. Gleiches gilt für den Destruktor. Wenn sowieso nichts drinsteht, weglassen. Du solltest die Variable count im VectorFilled-Konstruktor mit 0 initialisieren. Wenn du count bei jedem Schleifendurchlauf in vectorFilledPrices wieder auf 0 setzt, wirst du nicht über 1 hinauskommen. Du brauchst gar nicht mitzuzählen, wieviele Elemente du in den vector gesteckt hast. std::vector hat eine size-Methode, die dir genau das zurückgibt. Es ist nicht ersichtlich, warum ReadVector von VectorFilled erbt. Public-Vererbung drückt eine "ist-ein"-Beziehung aus. Ein ReadVector ist ein VectorFilled? Klingt komisch, aber dazu siehe oben. Deine Fehlerbehandlung der Eingabe ist fehlerhaft. Du prüfst zwar auf cin.fail, aber erst, nachdem du einen möglicherweise fehlerhaft eingelesenen Wert in den Vector gesteckt hast. Siehe lilith2k3s Code für eine bessere Eingabeschleife. Der Parameter wert in vectorFilledPrices verdeckt den gleichnamigen Member. Welchen Zweck hat der Parameter überhaupt? Weder wird darüber ein Wert an vectorFilledPrices übergeben, noch wird einer rausgegeben. Dann leg doch besser eine lokale Variable in vectorFilledPrices an. Und wozu gibt es diesen Member überhaupt? Und warum Zeiger? "== true" ist überflüssig. Du hast schon einen bool-Ausdruck, daran ändert sich nichts, wenn du ihn nochmal mit true vergleichst.

Dann wird's das sein. Du kannst es nicht in der Funktion machen, weil du den Zeiger auf den reservierten Speicher für die weitere Verarbeitung rausgibst. Wenn du ihn vorher wieder freigibst, gibt die Funktion einen ungültigen Zeiger zurück, und das Programm fliegt dir um die Ohren - wenn du Glück hast. Du speicherst den zurückgegebenen Zeiger ja in der Variablen wort. Es reicht also, wenn du nach der Verarbeitung das hier einbaust: delete[] wort;

Keine Ahnung, ich kenne den Rest deines Codes nicht. Vielleicht ist da irgendwo noch ein delete[]. Es ist auch nicht sicher, dass das das einzige Leck ist. Dein Programmiersteil zeigt eine gewisse Sorglosigkeit im Umgang mit dynamischem Speicher. Ich könnte mir vorstellen, dass es noch andere Stellen gibt. Zum Beispiel so: delete[] wort; Das kommt dann dahin, wo du den dynamisch reservierten Speicher nicht mehr brauchst. Ich rede vermutlich gegen die Wand, aber wenn du das gleich mit den Klassen der Standardbibliothek statt mit rohen Zeigern gemacht hättest, hättest du dieses Problem jetzt nicht

Du hast mindestens eine Stelle im Code, an der wiederholt ein malloc/new stattfindet, ohne dass der reservierte Speicher mit free/delete wieder freigegeben wird. So wird nach und nach immer mehr Speicher verbraucht.

Ok, die Darstellung als Zweierkomplement mit Komma halte ich für ungewöhnlich. Ist denn jetzt klar, wie man auf die Werte kommt?

Woher hast du denn diese Werte? Im Aufgabentext stehen sie nicht. In Q0.3 passen Werte >= 1 auch gar nicht rein.

Dann heißt die Datei nicht ma.cpp oder liegt nicht in deinem Home-Verzeichnis.

Dann liegt der Fehler vermutlich in dem Teil des Codes, den du nicht gezeigt hast, irgendwo hinter // buffer in DB schreiben

Warum schlägt man sich freiwillig mit fread und malloc herum, wenn man C++ zur Verfügung hat? ifstream f("file.p12", ios_base::binary); f >> noskipws; vector<char> buffer; // copy the file into the buffer: copy(istream_iterator<char>(f), istream_iterator<char>(), back_inserter(buffer)); // buffer in DB schreiben .... [/code] Zu deinem Problem: lSize ist 2724, aber result ist 59?

Weil (schon wieder) die Nullterminierung fehlt. In C gibt es keine Strings. Darum benutzt man Arrays von char dafür. Arrays haben aber ein paar Eigenheiten. So geht beispielsweise die Größeninformation verloren, wenn man ein Array als Funktionsparameter übergibt. Darum hat man die Vereinbarung getroffen, dass das Ende eines Strings durch ein spezielles Zeichen markiert wird. Ansonsten weiß keine C-Funktion, wo dein String aufhört, weder strlen noch printf noch sonst irgendeine. Da du offenbar unbedingt mit rohen char-Arrays hantieren willst, musst du dich an diese Konvention halten. Die ist komplett überflüssig. Die Variable "lenge" benutzt du nirgends. Und ansonsten rufst du nur den std::string-Konstruktor für char* auf. Das geht aber auch, ohne da noch eine Funktion drumherum zu stricken: // statt std::string s = arraytostring(einchararrayoderzeiger); // besser std::string s(einchararrayoderzeiger); [/code]

Laut Dokumentation benutzt OpenCV in der Debug-Konfiguration Access Violations für die Fehlerbehandlung. Kannst du mal einen Debugger dranklemmen?

Ein VLA ist genauso dynamisch wie ein mit malloc reserviertes Array. Malloc ist aber intern viel aufwändiger, und man darf das free nicht vergessen. Allerdings unterstützen nicht alle Compiler VLAs.

Nachtrag: Mein Fehler, das ist natürlich Blödsinn. fread gibt nicht die Anzahl der Bytes zurück. Insofern passt 1. Wie groß ist die Datei denn? Und an welcher Stelle wird abgebrochen? Ist das überhaupt eine Textdatei?

ifstream myfile(unitifile[B].c_str()[/B]);

Dann ist man aber nicht mehr kompatibel zu C Wenn man Code hat, der sowohl als C als auch als C++ compilierbar sein soll, dann muss man den Rückgabewert von malloc casten. Dann muss man aber auch noch etliche andere Dinge beachten.

Er will es doch unter Windows compilieren. Hast du das über die ganz normale Eingabeaufforderung gestartet oder über den Visual Studio Command Prompt? Nur im letzteren sind die Pfade zu Compiler und Linker automatisch gesetzt.

if (menge != 1)Warum brichst du ab, wenn dir ein Lesevorgang, der 16 Bytes lesen soll, nicht genau 1 Byte liefert? Menge sollte doch üblicherweise 16 sein, am Ende der Datei vermutlich weniger. Du kannst nicht davon ausgehen, dass fread dir die vollen 16 Bytes liefert. Das ist aber kein Grund zum Abbrechen. Statt dessen musst du das in der Ausgabeschleife berücksichtigen.

Hast du denn die Ausgabe auch dementsprechend geändert? Du musst jetzt 16 Einzelzeichen ausgeben, nicht mehr nur 1.

Fehlerquellen eliminieren: char* stringtoarray(string line) { char* charline=new char[line.length()+1]; strcpy(charline, line.c_str()); return charline; }[/code] Ein Speicherleck haben wir dann zwar immer noch, aber sonst sollte das so funktionieren. Ich sehe im Code keine Eingabeverarbeitung.

Hast du deine stringtoarray-Funktion denn soweit repariert, dass sie eine Nullterminierung anhängt?