Klotzkopp

Eine schwache oder eine starke? Warum brauchst du dafür eine KI? Das kann ein "dummes" Spracherkennungsprogramm auch.

Ich rate dir, zuerst deine Einrückung in Ordnung zu bringen. Das sieht grauenhaft aus. Aus dem Code, den du gezeigt hast, ist nicht zu erkennen, wo das Problem liegt. Ich vermute, dass in FillDaten etwas schief läuft. Warum liest du die Dateien eigentlich nicht nacheinander ein? Dann könntest du dir dieses Gehampel wegen der unterschiedlichen Dateilängen sparen.

Lies doch mal den Text bis zum Ende. Da steht: "Nothing in Visual Basic".

...................

Es ist dir vielleicht nicht klar, aber dein "Problem" ist eigentlich ziemlich trivial. Einen passenden Algorithmus kannst du sehr leicht aus dem echten Leben entnehmen. Angenommen, du sammelst irgendwelche Sammelkarten, und du willst keine doppelten. Jetzt kaufst du ein neues Paket. Wie stellst du sicher, dass du die doppelten aussortierst, bevor du sie in deine Sammelkiste packst? Du vergleichst jede Karte in deiner Sammelkiste mit der ersten Karte aus dem Paket. Wenn du dabei keine Karte findest, die der neuen gleicht, kommt die neue in die Kiste. Ansonsten nicht. Dann machst du das gleiche mit der nächsten Karte im Paket. Jetzt ersetzt du "Paket" durch "Array", "Karte" durch "Name" und "Sammelkiste" durch "Combobox". Fertig

Du hast nur eine Variable "ausgabe", und da schreibst du die gefundenen Primzahlen rein. Dabei überschreibst du den Wert, der vorher drinstand. Logisch, dass dann hinterher nur die letzte drinsteht.

Rückst du den Code grundsätzlich nicht ein, oder ist das irgendwo unterwegs verloren gegangen? Passt nicht zum Code. Zeile 79 ist nicht mehr in der main-Funktion. Welche Zeile soll das sein? Übrigens: gets ist böse.

Geh doch mal mit dem Debugger schrittweise durch die Funktion, damit du siehst, was beim zweiten Mal passiert. Nachtrag: Das Problem könnte sein, dass der Speichern-Dialog dein Current Directory ändert. Um das zu verhindern, gib das Flag OFN_NOCHANGEDIR an.

Als ersten Schritt nicht an 127.0.0.1 senden? Du hattest doch oben schon einen Broadcast.

Doch, hast recht. Also, weniger die Gefahr eines Pufferüberlaufs (man kann ja immer noch einen zu großen Wert angeben), als das umständliche Hantieren mit char-Arrays und -Zeigern und dem Problem, dass man nie wissen kann, wieviele Zeichen der User eingibt.

Lieber nicht mit cin.getline, weil man da nur einen char-Zeiger angeben kann -> Gefahr eines Pufferüberlaufs. Lieber std::getline, da kann man auch direkt in einen std::string einlesen. Also: getline(cin, name);

Ist doch ganz einfach. In der Platte ist Luft, damit die Köpfe auf einem Luftkissen schweben können. Im Vakuum entweicht die Luft aus der Platte -> die Köpfe heben nicht ab -> Platte kaputt.

Weil Festplatten einen gewissen Luftdruck brauchen, damit die Leseköpfe richtig fliegen. Und da zumindest handelsübliche Modelle nicht luftdicht sind, ist das im Vakuum nicht möglich.

Aus der Beschreibung zu ChangeDisplaySettingsEx:

Wenn du Run-Time Dynamic Linking verwendest, wird der Compiler die Funktion nie "finden", weil du sie erst zur Laufzeit bindest (daher der Name), da hat der Compiler seine Arbeit längst abgeschlossen. In der MSDN Library gibt es übrigens ein schönes Beispiel.

Bitte poste ab jetzt die vollständige Fehlermeldung des Compilers und kennzeichne die Stelle im Programm. In C und C++ muss Programmcode immer in einer Funktion stehen. Außerdem brauchst du den Rückgabewert von LoadLibrary für den Aufruf von GetProcAddress, es wäre also gut, wenn du dir den in einer Variablen merken würdest. Ist auch recht hilfreich für die Fehlerdiagnose.

Wie wäre es, wenn du eine bessere Fehlerbeschreibung als "hat nicht funktioniert" lieferst?

Durch Runtime Dynamic Linking. Stichwort LoadLibrary/GetProcAddress. Wenn du eine Headerdatei und eine Importbibliothek (.lib) hast, kannst du auch Load Time Dynamic Linking benutzen. Dafür musst du die Headerdatei mittels Includedirektive einbinden und die .lib-Datei über die Projekteinstellungen oder mit einer Pragmadirektive dazulinken.

Wenn OnReceive gar nicht aufgerufen wird, ist es doch ziemlich egal, was du darin versuchst, oder? Erstellst du auch noch irgendwo anders eine Instanz von CMySocket für den Empfang, die etwas länger lebt, als die in CNetzwerkView::OnButton1, die ja gleich nach dem Senden wieder zerstört wird? Die Instanz, die du (komplett sinnlos) in OnReceive erstellst, kommt dafür übrigens nicht in Frage, weil ja schon eine Instanz da sein muss, damit OnReceive überhaupt aufgerufen wird.

Dass du sie nicht eingeschaltet hast, bedeutet nicht, dass es sie nicht gibt

Üblicherweise macht man das mit Schiebe- und binären Verknüpfungsoperatoren. Wenn du die nicht zur Verfügung hast, kannst du auch mit wiederholter Division durch zwei und Prüfen des Divisionsrests arbeiten.

Lass dir doch mal alle Pfade, die so entstehen, per MessageBox ausgeben.

Solange du wirklich if meinst, und nicht #if.

Solange du an deinen #define-Direktiven festhältst, wirst du immer dieses Problem haben. Du kannst durch Laufzeitbedingungn (Parameter) nichts mehr beeinflussen, was bereits durch Compilezeitbedingungen (defines) entschieden wurde. Wenn dein Programm kompiliert ist, enthält es nur eine Version dieser Funktionen. Daran kannst du nachträglich nichts ändern. Du musst dir etwas anderes einfallen lassen. So geht's nicht.

Dann musst du dich zur Compilezeit für eine entscheiden. Zur Laufzeit hast du keinen Einfluss mehr darauf. Mit gleichem Namen? Gar nicht. Du könntest so etwas machen: #define VL_MODE 0 #define FUNCTION FUNCTION_NULL #include "STDFLIFO.h" #define VL_MODE 1 #define FUNCTION FUNCTION_EINS #undef INCLUDE_GUARD_VON_STDFLIFO_H #include "STDFLIFO.h"[/code] Das ist allerdings ziemlich blutig und klappt nur, wenn du für jede Funktion, Variable und Typ in der Headerdatei neue Namen definierst. Mein Rat: Lass es. Der Ersteller dieser Datei hat sich vermutlich etwas dabei gedacht, als er VL_MODE als Compilezeitkonstante festgelegt hat.