Klotzkopp

Bitte gewöhne dir doch aussagekräftige Threadtitel an. Dass das Problem "dringend" ist, mag zwar zutreffend sein, hilft aber nicht bei der Lösung. Und die multiplen Ausrufezeichen helfen auch nicht. Ich habe das in diesem Thread mal für dich erledigt.

Darüber lässt sich streiten. Die Bugliste von Dev-C++ ist ziemlich lang, und das letzte Release ist sogar noch ein paar Monate älter als dieser Thread, den du hier ausgegraben hast. Das sind bald 3 Jahre.

std::vector hat gar keine append-Methode. std::string hat zwar eine, aber das ist ja hier irrelevant.

Das muss ja nicht generell so sein, sondern vielleicht nur bei dem Compiler, den Mattscheibe benutzt.

Warum? Mathematisch gesehen ist das zwar dasselbe, aber durch die eingebaute Ungenauigkeit der Fließkommatypen sind die bei der exp/ln-Variante entstehenden Rundungsfehler größer als bei einer eigenen pow-Implementierung.

Doch, das mach TCP für dich, aber du scheinst zudem noch zu erwarten, dass das auf der Empfängerseite dann auch genau so wieder zusammengesetzt wird. Das passiert aber nicht. Du liest mit einem recv-Aufruf (oder read oder wie auch immer) genau so viel aus dem Socket aus, wie eben gerade da ist. Es gibt keine "Nachrichten", nur Bytes. Wenn du ein nachrichtenbasiertes Protokoll über Sockets laufen lassen willst, musst du es schon selbst implementieren. Ich kenne diese API nicht, aber die Tatsache, dass da nirgends eine Längenprüfung zu sehen ist, bestärkt mich in meiner Vermutung. Du bist selbst dafür verantwortlich, dass du eine vollständige "Nachricht" einliest. Es reicht nicht, dass du in.available() prüfst, weil das vermutlich zwischenzeitlich auch mal 0 liefern kann, wenn die Gegenstelle mit dem Senden nicht nachkommt (zum Beispiel eben genau dann, wenn Sender und Empfänger auf demselben Rechner laufen, und der Prozessor gerade den Empfänger bearbeitet). Wenn der Empfänger nicht weiß, aus wievielen Bytes eine Nachricht besteht, musst du diese Information mitschicken, z.B. indem du der Nachricht die Länge voranstellst. P.S.: Kann es sein, dass du durch das erste read (außerhalb der Schleife) das erste Byte der Antwort wegwirfst?

Es ist schon irgendwie drollig, dass du im selben Beitrag schreibst: Das ist nämlich dein Problem, und nicht das deines Chefs. Du forderst Kulanz ein, bist aber anscheinend selbst nicht dazu bereit, welche zu gewähren. Deine Einstellung zur Arbeit sei dir belassen, aber du solltest dich IMHO nicht wundern, dass du damit aneckst, sei es beim Chef, bei Kollegen oder in Foren.

Woraus schließt du das? Die Tatsache, dass du von "TCP-Nachrichten" und "Socket-Nachrichten" sprichst, lässt mich vermuten, dass du erwartest, dass das, was du auf der einen Seite auf einmal reinsteckst, auch auf den anderen Seite auf einmal rauskommt. Das ist nicht der Fall. Auf Socket-Ebene gibt es keine "Nachrichten", nur einen Strom von Bytes. Es kann durchaus sein, dass du die Daten, die du mit einem einzigen send-Aufruf abgeschickt hast, mit mehreren recv-Aufrufen einsammeln musst. Ob das passiert, hängt auch vom Timingverhalten der Programme ab. Das könnte auf das beobachtete Verhalten passen.

Was ist denn nicht neu für dich - sprich: Welches Vorwissen hast du? Also wenn man bei Google "OLEDB C++" eingibt, findet sich da so einiges, z.B. auch das hier: OLE DB Consumer Templates (C++) Auch interessant könnte das hier sein: OLE DB Programmer's Guide Du kannst natürlich auch eine der Hilfsbibliotheken auf CodeGuru oder CodeProject verwenden, wenn dir das erlaubt ist. Das ist so ein Problem. Datenbanken mit C++ ist ein nicht besonders einsteigerfreundliches Thema. Eine Beispielanwendung für OLEDB ist IMHO niemals "klein".

Das ist nicht weiter verwunderlich, weil ASCII keine deutschen Umlaute enthält. Kannst du das ein wenig ausführlicher schildern als mit "irgendwie klappt das bei mir nicht"? Ich würde zunächst einmal klären, in welcher Codierung die Daten überhaupt ankommen.

Das ist schon mal grundsätzlich ein fragwürdiger Ansatz, eben weil ein Array eine Menge von Objekten desselben Typs ist. Mach es so wie qat es vorgeschlagen hat: Nimm ein eindimensionales Array einer Struktur, die eine Reihe repräsentiert. Ich weiß nicht, wie du darauf kommst.

\t ist schon richtig. Zeig doch mal, was du versucht hast.

Ich mache hier mal dicht, da ich nicht glaube, dass hier noch etwas Sinnvolles passiert. burge, du kannst dir bitte die Mühe machen, - die Aufgabenstellung ordentlich abzuschreiben, - zu zeigen, was du bisher geschafft hast, und - zu erläutern, wo genau du Probleme hast. Deine Hausaufgaben wird hier niemand für dich machen.

Mir sind noch zwei Dinge aufgefallen: - Du berücksichtigst Präprozessordirektiven nicht. Das ist aber auch nicht so leicht umzusetzen. - Du berücksichtigst Trigraphs (und seit C99 auch Digraphs) nicht.

Aber du siehst jetzt hoffentlich, was du davon hast. Du hast zwar ein Programm, aber du weißt nicht, wie es funktioniert, du kannst nicht mal beurteilen, ob es funktioniert. Wer immer dir dabei geholfen hat, hat dir keinen Gefallen getan.

Dafür, dass du also die Aufgabe nicht genau verstanden hast, ist das Programm aber ziemlich gut. Du bist entweder ein Naturtalent oder du hast es vielleicht doch nicht ganz allein geschrieben Du berücksichtigst //-Kommentare nicht. Gut, die sind erst seit C99 erlaubt, aber immerhin verwendest du sie selbst. Klar, mit entsprechenden Tests. Kaum. Abgesehen davon, dass der Compiler kaum feststellen kann, wo eine Klammer fehlt (sondern nur, dass), war das laut dem einleitenden Kommentar auch nicht gefordert.

Ich vermute, dass du in deinem Programm irgendwelche Annahmen über das aktuelle Verzeichnis oder argv[0] triffst, die bei der Ausführung über die Batchdatei nicht erfüllt sind. Benutzt du relative Pfade? Ohne eine genauere Fehlerbeschreibung als "ein fehler" kann man dazu kaum mehr sagen.

Um aus den Stunden die Minuten zu ermitteln, musst du den Wert mit 60 multiplizieren. Dann musst du aber noch die vollen Stunden (also die Vielfachen von 60) rausrechnen, und das kannst du tun, indem du den Rest der Division durch 60 ermittelst (also % 60).

Das ist aber weder C noch C++.

Ich weiß nicht, was du mit Auskitzeln meinst. Eigentlich möchte ich nur ordentliche Fehlerbeschreibungen. Wenn du immer nur "geht nicht" sagst, kann man dir nicht weiterhelfen. Du gehst doch auch nicht zum Arzt und sagst "Ich hab irgendwie Schmerzen" und sonst nichts. Was meinst du? Ich habe gesagt, du sollst stat und localtime benutzen. Du hast gesagt, das hättest du schon getan, und auf "bösse" verwiesen. Unter "bösse" steht aber nichts von stat oder localtime, also hast du es offenbar doch noch nicht getan. Ja, das ist toll. Da du es aber wieder mal nicht geschafft hast, den dazugehörigen Code zu zeigen, kann ich dir nur sagen: Du machst etwas falsch. Eine PN? Ich habe keine bekommen.

Unter "bösse" (was soll das eigentlich heißen? Meinst du "böse"?) benutzt du weder stat noch localtime. Ich sehe da nur auskommentierten WinAPI-Code. Ja, das ist auch eine tolle Fehlerbeschreibung

Hol dir mit stat die Zeit für jede gefundene Datei und wandle sie mit localtime in struct tm um. Den sprintf-Aufruf musst du dann auch entsprechend anpassen.

Es ist gar nicht Aufgabe des Compilers, das Programm zu starten. Er soll es nur übersetzen. Das entscheidende ist übrigens nicht die Warnung, die du hier gepostet hast, sondern die Fehler danach, die leider nur im Screenshot zu sehen sind. Warum verwendest du eigentlich immer noch opendir/readdir? Ich dachte, du wolltest die WinAPI benutzen? Mein Code geht davon aus, dass du FindFirstFile/FindNextFile benutzt. Du kannst meinen Code nicht einfach irgendwo in deinen reinklatschen. Ein wenig Mitdenken wäre schon angebracht. Ich schrieb doch:

Und das ist eine Warnung, kein Fehler. Da steht sogar, was das Problem ist, wie du es vermutlich beheben kannst, oder wie du die Warnung abschaltest (wovon ich abrate). Zeig doch mal die Zeile, die die Warnung verursacht.

Nein, ich werde nicht deine Arbeit machen. Glaubst du, mit dieser Fehlerbeschreibung kann dir irgendjemand helfen?