Klotzkopp

Wir haben ein Java-Forum -> Verschoben. Da es dort allerdings von "Java- Programmieraufgaben" nur so wimmelt, mache ich den Threadtitel noch ein wenig aussagekräftiger. Beim nächsten Mal bitte selbst dran denken. Davon abgesehen wäre es hilfreich, wenn du schilderst, wo jetzt konkret das Problem ist. Kannst du Teile von Strings ersetzen?

Ich kann dich helfen. Dein Problem hat nichts mit C oder C++ zu tun. Verschoben: Skript- und Webserverprogrammierung

Wolltest du das nur mitteilen, oder hast du auch eine Frage? Dann sollte da schon ein wenig mehr kommen als "funzt ned".

Es ist egal. Ohne & ist es (laut Standard) ein "function designator", mit & ist es ein Funktionszeiger. Da beim Funktionsaufruf Function-Designator-Parameter aber sowieso in Funktionszeiger umgewandelt werden, ist das Ergebnis dasselbe. Wenn man es mit & schreibt, fällt eine implizite Konvertierung weg.

Das ist soweit in Ordnung. Wenn du in deinen Threads Funktionen der C-Laufzeitbibliothek benutzt, solltest du _beginthreadex benutzen, nicht CreateThread. Die Funktion asctime ist nicht threadsicher, weil sie immer wieder denselben Puffer zurückgibt. Aus so einem Codefragment kann man nicht ablesen, was sonst noch unsicher sein könnte, weil da jede Menge Variablen sind, deren Typ und Scope nicht klar ist. Was heißt denn "macht Probleme"? Fehlermeldung? Was sagt der Debugger? Synchronisierungsprobleme machen sich nicht zwangsläufig da bemerkbar, wo sie verursacht werden. Du kannst das nicht absichern, indem du das Programm zum Test laufen lässt und da, wo es knallt, eine CritSec drumherum packst. Wie stellst du sicher, dass die Threads dann auch wirklich beendet sind?

Benutzen denn alle Threads dieselbe Critical Section? Ansonsten bringt das gar nichts. Wie und wo ist Cout deklariert?

Die Abweichungen können sogar mehr als geringfügig sein, allerdings nur nach oben: All diese Funktionen warten mindestens für die angegebene Zeit. Es kann auch länger dauern. Es kann theoretisch sogar sehr sehr lange dauern, wenn andere Prozesse mit höherer Priorität beschäftigt sind. Nur Echtzeitbetriebssysteme können Obergrenzen bei der Reaktionszeit garantieren.

Macht nicht, hab's schon verschoben

sendMessage und writeMessage sind Methoden der Klasse SenderEmpfaenger, also brauchst du zum Aufrufen eine Instanz dieser Klasse (oder eine Referenz oder einen Zeiger darauf). Anbieten würde sich natürlich die, die du in main erzeugt hast. Normalerweise würde man in so einem Fall dem Thread einen Zeiger auf die SenderEmpfaenger-Instanz übergeben, und nicht 12 (warum eigentlich 12?). Übrigens ist strlen(a.c_str()) eine ziemlich holprige Lösung. std::string hat eine length-Methode. Zu deinem Linkerproblem: Wie du in der Doku zu den Funktionen nachlesen kannst, die da nicht aufgelöst werden konnten, musst du Ws2_32.lib linken.

Anstatt dieselbe Frage zu wiederholen (siehe dazu auch die Boardregeln bezüglich "Threadpushing"), könntest du dich fragen, warum niemand antwortet. Im Ernst, was soll diese Frage? "Ich habe hier eine Funktion, die fehlschlagen kann. In diesem Fall kann mein Programm an dieser Stelle nicht weiterlaufen. Sollte ich diesen Fall abfangen und irgendwie behandeln?" Selbstverständlich solltest du das.

Es gibt (noch) keine portable Lösung, um eine bestimmte Zeit zu warten. Unter Windows gibt es Sleep, unter Linux sleep/usleep/nanosleep. Die boost-Bibliothek hat auch eine sleep-Methode in ihrer Threadklasse. Du könntest aber auch einfach noch eine Eingabe einlesen: cin.get();

Wenn die Funktion in der DLL nicht gefunden wird, gibt GetProcAddress NULL zurück. Wie lautet die genaue Fehlermeldung, und wie sieht der Code dazu aus?

Ist die Frage ernst gemeint? datum = "Inhalt"; oderdatum = string_in_dem_wirklich_was_drinsteht.substr( x, y ); Oder durch Einlesen von cin, so wie du es mit dem String zeitstempel machst. Was davon im Kontext deines Programms sinnvoll ist, musst du dir schon selbst überlegen. Du wirst dir beim Anlegen der Variablen ja etwas gedacht haben, oder?

Nein. Außerdem gibst du so nicht die Länge vor, sondern deklarierst ein Array von Strings. Grundsätzlich solltest du in einen String erst einmal etwas hineinstecken, bevor du versuchst, etwas herauszuholen. Du versuchst, Substrings aus einem String zu holen, in dem nichts drinsteht.

Der erste Parameter von std::string::substr darf nicht größer als die Länge des Strings sein. Wenn du versuchst, aus einem leeren String (datum) ab Position 3 oder 6 etwas rauszuholen, dann ist es nicht verwunderlich, dass dir das um die Ohren fliegt.

Also sollst du die Dateien aneinanderhängen, mit einem Zeilenumbruch dazwischen? Das ist schon mal ein großer Schritt vorwärts. Dann ist meiner Meinung nach nur noch offen, in welcher Reihenfolge das geschehen soll. Kommt A vor B (und nicht etwa B vor A), weil die Dateinamen alphabetisch sortiert werden? Oder kommt da ein anderes Kriterium zum Tragen?

So: typedef void(*pFunc)(unsigned char*); mcbe_RechneMitZeile ist ja auch kein gültiger Bezeichner an dieser Stelle. Du musst die Funktion über den Funktionszeiger aufrufen. Das könnte so aussehen: pFunc( input64 ); Das heißt, falls das Array input64 als Parameter für diese Funktion gedacht ist. jbyte könnte auf unsigned char passen.

Zwischen GetProcAddress und FreeLibrary fehlt der Aufruf der Funktion. Der Funktionszeigertyp pFunc muss auf die Signatur der Funktion passen. Die sollte ja aus der Headerdatei der C-DLL hervorgehen. Ich glaube nicht, dass der richtig ist, denn eine C-Funktion dürfte kaum jbyte als Parameter- oder Rückgabetyp haben.

Auch das ist nicht sicher. Du hast nicht gezeigt, wo die Variable hochgezählt wird, aber stell dir mal vor, zwischen dem Hochzählen und dem Zusammenbasteln des Dateinamens zählt ein anderer Thread die Variable nochmal hoch. Oder zwischen den Zuweisungen von dat und dat[i+1]. Das alles kann passieren. Globale Variablen sind nicht threadsicher. Das ist kein gutes Zeichen. Du kannst durch Rumbasteln die Wahrscheinlichkeit, dass so ein Synchronisierungsproblem auftritt, einschränken, aber du kannst es nie völlig ausschließen. Im besten Fall sorgst du nur dafür, dass sich der Fehler schlechter reproduzieren und damit kaum mehr aufspüren lässt. Es kann auch sein, dass deine Basteleien bewirken, dass das Programm auf deinem Rechner stabiler läuft, auf anderen dafür umso schneller abstürzt. Allein die Sleep-Aufrufe in deinem ersten Beitrag sind schon höchst verdächtig. Lass mich raten, damit läuft es besser? Threads sind kein einfaches Thema, weil Threadsynchronisierung kein einfaches Thema ist. Da du die WinAPI verwendest, wäre der erste Schritt, dass du dich in die Synchronisierungsobjekte der WinAPI-Threads einarbeitest: Events, Critical Sections, Mutexe, Semaphoren, Condition Variables (ab Vista/Server 2008). Für dich sind vermutlich zunächst Critical Sections und die Interlocked...-Funktionen interessant: Using Critical Section Objects (Windows) InterlockedIncrement Function (Windows)

Double.ToString Method (String) (System)

Das Problem war möglicherweise, dass die Frage so gestellt war, dass sie nicht beantwortet werden konnte. Soweit ich weiß, gibt es kein eigenes Event fürs Minimieren. Du kannst das aber über das Resize-Event behandeln. Dann eröffne bitte einen neuen Thread. Eine Frage - ein Thread, ein Thread - eine Frage.

Dann hast du die Importbibliothek für kernel32.dll immer noch nicht richtig dazugelinkt. Die Funktionen aus der C-DLL wirst du sowieso nicht direkt aufrufen können, weil du für diese DLL keine Importbibliothek hast. Du musst dir mit LoadLibrary/GetProcAddress die Funktionszeiger aus der DLL holen und diese aufrufen. Logisch. Wenn du keine Funktionen aus kernel32.dll benutzt, brauchst du sie auch nicht.

Gar nicht, macht aber nichts Abgetrennt und zu Anwendungssoftware verschoben.

Indem du searchString nicht mit einem Literal, sondern mit dem Text aus der Textbox initialisierst?

Da ist aber von kernel32 nichts zu sehen. LoadLibrary ist auch in Kernel32.dll.