Klotzkopp

Der Compiler beanstandet Zeile 1 in waehrung.dat. Es wäre also hilfreich, wenn du uns zumindest den Anfang dieser Datei zeigen würdest.

Wenn im if-Zweig deiner fak-Funktion immer noch keine return-Anweisung steht, dann ist das aber eher Zufall.

Ich muss mich korrigieren: Defaultparameter gibt's nur in C++, nicht in C.

Dein Compiler sollte diesen Code eigentlich nicht akzeptieren, oder zumindest eine Warnung ausgeben, denn im if-Zweig gibt deine Funktion nichts zurück. Nur im else-Zweig ist eine return-Anweisung. Ja.

Ist bekannt. Die Boardsoftware hat für nicht angemeldete Benutzer eine voreingestelle Zeitzone, die sich nicht automatisch umstellt.

Man könnte dir besser helfen, wenn du ein paar mehr Informationen lieferst. Zum Beispiel die Ergebnisse deiner lokalen Fehlerdiagnose. Browser-Version, Cookies aktiv, Javascript eingeschaltet, so etwas. Ansonsten können wir nur auf allgemeine Fehler prüfen, die aber offenbar nicht vorliegen, weil andere User keine Probleme mit dem Erstellen der Stellenanzeige haben.

Da AWT unter Windows nur ein dünner WinAPI-Wrapper ist, sollten die erzeugte Fenster ganz normale Windows-Fenster sein.

Du lieferst nicht annährend genug Informationen, dass man das Problem nachvollziehen könnte. Du lieferst deine Diagnosen "bleibt leer", "wird nicht initialisiert", aber die helfen nicht weiter, weil nicht klar ist, wie du zu diesen Erkenntnissen gelangt bist, denn dabei kann auch einiges schief gehen. Am besten zeigst du ein vollständiges kompilierbares Minimalbeispiel, das das Problem reproduziert. Zumindest solltest du zeigen, wie und wo du p$_insert aufrufst. Da die Methode private ist, kann das ja eigentlich nur im TABLEMAP-Konstruktor passieren. Wenn das nicht geht, dann schreib bitte zu deinen Interpretationen die konkreten Beobachtungen dazu, die dazu geführt haben, z.B. "Der Debugger hat an dieser Stelle im Code für diesen Ausdruck diesen Wert angezeigt".

Jeder Zeiger ist (in C) implizit in void* konvertierbar. void* ist in C sozusagen der generische Datentyp. Er signalisiert, dass man da alles reintun kann, was man will, dass man dafür aber auch selbst verantwortlich ist. Ein char*-Parameter signalisiert etwas ganz anderes. Zudem müsste man dann casten, sobald man etwas anderes übergeben will.

Mit pthread_attr bist du da auf dem Holzweg, keine Ahnung, woher du die Idee hast. Alle Parameter werden an pthread_create übergeben. Aber nur der letzte landet in deiner Threadfunktion. Du hast ihn dort arg genannt. Dann kommt eben NULL in deiner Threadfunktion an, das ist aber nicht besonders nützlich, wenn du Daten mit dem Thread austauschen willst.

Du musst an der Deklaration von a gar nichts ändern. Du musst dafür sorgen, dass a auf einen Speicherbereich zeigt, der groß genug ist, und auf den du schreibend zugreifen kannst. Du kannst a natürlich statt als Zeiger gleich als hinreichend großes Array deklarieren. Das ist ein Array von Zeigern, das ist Unsinn. Du kannst ein char-Array mit einem Stringliteral initialisieren: char a[255] = "Hallo Welt"; Aber du kannst einem Array nichts zuweisen, du musst also mit strcpy/strcat arbeiten.

Der "String" ist ein sogenanntes Literal. Der Speicher für Stringliterale wird automatisch bereitgestellt, darum brauchst du dich nicht zu kümmern. Der Standard sagt, dass man auf den Speicher von Stringliteralen nur lesend zugreifen darf. Anhängen ist ein Schreibzugriff und damit verboten. Der technische Grund ist, dass der Speicher für Stringliterale zwar automatisch bereitgestellt wird. Aber eben nur genau so groß, wie er sein muss. Dahinter ist einfach kein Platz zum Anhängen, da stehen bereits andere Inhalte, die dann überschrieben würden. Auf manchem Systemen werden Stringliterale auch durchaus in Speicher abgelegt, der zur Laufzeit wirklich nur gelesen werden kann. Wenn du willst, dass a auf einen Speicherbereich zeigt, in dem du Anhängen darfst, dann darf a eben nicht auf ein Literal zeigen.

Mit OutputDebugString kannst du einen Text im Debug-Fenster ausgeben lassen (oder mit DebugView mitlesen). Das Konzept nennt sich RAII Kommt vermutlich von C. So ähnlich. Wenn du ein stream-Objekt in einem Kontext benutzt, wo ein Wahrheitswehrt gefragt ist, entspricht der Wert dem negierten Rückgabewert von fail(). Immer, wenn das badbit oder das failbit des Streams gesetzt ist: Wenn die Datei nicht geöffnet werden konnte, wenn du am Dateiende angelangt bist, wenn du mit >> in den falschen Typ einliest. std::string ist ein typedef von std::basic_string, der ist auf dieser Seite auch gelistet.

In deinem ersten Beitrag hast du von den letzten 3 Zeichen der Datei geschrieben. Das ist nur dann immer die gleiche Stelle, wenn die Datei immer gleich lang ist. Ist das der Fall?

Hab ich doch geschrieben. fseek ist unter Windows unzuverlässig, wenn die Datei im Textmodus geöffnet wurde. Ansonsten würde das funktionieren.

Ja, bis deine Datei mal irgendwann drei Zeilen hat. Es wäre möglicherweise besser, gleich das allgemeine Problem zu lösen. Deine Berechnung, wo die letzten drei Zeichen einer Zeile anfangen, können dich vor den Anfang der Zeile bringen, wenn die Zeile weniger als drei Zeichen enthält. Und das erzeugt undefiniertes Verhalten.

Lies zeilenweise aus der Datei, bis du das Ende der Datei erreichst, dann ermittle die letzten 3 Zeichen der zuletzt eingelesenen Zeile. Beachte, dass die letzte Zeile möglicherweise kürzer als 3 Zeichen ist.

Hier geht es um C++. Dann mach dafür bitte einen eigenen Thread auf. Sonst behandeln wir hier zwei komplett unterschiedliche Probleme quer durcheinander.

CFrameWnd::GetActiveView

Im gezeigten Code ist nichts, das irgendeine Ausgabe erzeugen könnte. Zum Code: Wenn du statt fstream ifstream benutzt, kannst du dir das ios::in sparen. open und close benutzt man normalerweise nicht. Für open gibt es den Konstruktor, für close den Destruktor. eof eignet sich nicht als Schleifenbedingung, weil das erst dann true ergibt, wenn das Lesen schon einmal fehlgeschlagen ist. Benutz besser std::getline aus <string>, dann bekommst du keine Probleme, wenn mal eine Zeile mehr als 80 Zeichen hat. // Open the file ifstream f("111.txt"; while (f.getline(charstrLine, 80)) { }[/code]

Da glaubst du richtig. Dazu gehört auch noch ein Copykonstruktor, der beim Kopieren von af2 aufgerufen wird. Durch das fehlende delete von p gibt es ein Speicherleck. Es muss delete[] pB sein.

Die Empfehlung ist an sich richtig, aber die Umsetzung ist falsch. strncat(x, y, strlen(y)) ist genau dasselbe wie strcat(x, y) strncat so zu benutzen, ist komplett sinnlos. Keine Ahnung, kann sein. In deinem Beispielcode machst du ihn jedenfalls nicht.

Der Längenparameter von strncat dient dazu, anzugeben, wieviel Platz im Zielstring noch ist, damit nicht mehr reinkopiert wird. Wenn du da die Länge des anzuhängenden Strings angibst, verhält es sich genauso wie strcat, und ist damit auch kein bißchen sicherer. Nein, wie gesagt: So wie du strncat benutzt, sollte es sich genau wie strcat verhalten. Entweder ist im Zielstring nicht genug Platz, oder die Speicherstruktur wurde vorher schon irgendwo beschädigt. Solche Fehler machen sich selten an der Stelle bemerkbar, an der sie verursacht werden. Das ist das "Schöne" an undefiniertem Verhalten: Es kann auch gut gehen. Dann änderst du etwas, und es knallt. Ausprobieren hilft da leider nicht. Kannst du ein Minimalbeispiel erstellen, das das Problem reproduziert?

Alle 3 Varianten sind funktional identisch. Wenn die erste bei dir Probleme gemacht hat, steckt vermutlich ein Bug irgendwo im Rest des Programms. Nachdem du den Rückgabewert von strcpy var1 zuweist, zeigt var1 auf den Anfang von var2. Es ist also völlig egal, mit welchen von beiden du str(n)cat aufrufst.

Aus dieser einzelnen Codezeile und deiner Beschreibung lässt sich der Fehler nicht erkennen. Zeig bitte mehr Code, am besten ein minimales Beispielprogramm, das den Fehler reproduziert.