Klotzkopp

Dann wirst du aber beim Lesen ohne vorheriges Schreiben ein Problem bekommen. Denn dann ist keine Datei zum Lesen da.

Hier fehlt es an Genauigkeit. Das Programm bricht nicht einfach ab, sondern es tritt eine Exception auf. Im Text dieser Exception steht auch, was das Problem ist: Du versuchst, eine Datei zu öffnen, die bereits geöffnet ist, durch den StreamWriter darüber. Ein Close wirkt hier Wunder. Und benutz doch bitte Code-Tags, damit die Einrückung nicht verlorengeht.

Das ist keine Verbesserung, wenn der Wert nicht drin ist, gehst du immer noch die gesamte Liste durch. Das muss nicht sein, du kannst unter Umständen schon früher aufhören. Sagen wir beispielsweise, du suchst die 5, und die Liste beginnt mit 8...

Bedenke bei a), dass du in der Regel nicht die ganze Liste durchsuchen musst.

Du machst aber nicht "+2 sternchen pro durchlauf". Der grundsätzliche Aufbau ist doch der: for(INIT; CONDITION; STEP) { BODY }[/code] Der Ablauf sieht so aus (das solltest du auswendig wissen): 1. INIT ausführen 2. CONDITION prüfen. Wenn falsch, dann Ende 3. BODY ausführen 4. STEP ausführen 5. Gehe zu 2 Wenn deine CONDITION niemals wahr wird, passiert (außer INIT) gar nichts. Und wenn du bei STEP doppelt so große Schritte machst, machst du nur halb so viele. Du überspringst quasi die Ausgabe jedes zweiten Sternchens. Das ist keine "zusätzliche" Formel. Du hast auch im ersten Programm die Anzahl der Sternchen aus der Zeilennummer berechnet, nur war dort die Formel einfacher: Zeile 1: 1 Sternchen Zeile 2: 2 Sternchen Zeile 3: 3 Sternchen ... Zeile n: n Sternchen Deswegen lautete die CONDITION: zeichen < zeile+1 (bzw. zeichen <= zeile). Du musst jetzt mit der Tabelle die Formel für den allgemeinen Fall des neuen Problems finden, um daraus die richtige CONDITION zu formulieren.

Bei 1 anzufangen, ist sicher richtig. Immer um 2 zu erhöhen, ist aber Quatsch. Dein Endwert erhöht sich bei jedem Durchlauf der äußeren Schleife um 2. Die Schrittweite der inneren Schleife hat damit nichts zu tun. Wenn du am Ende 11 Sternchen ausgeben willst, musst du von 1 bis 11 zählen, mit Schrittweite 1. Bei Schrittweite 2 zählst du 1, 3, 5, 7, 9, 11: Das werden nur 6 Sternchen. Versuch doch mal, eine allgemeingültige Regel aufzustellen: Zeile 1: 1 Sternchen Zeile 2: 3 Sternchen Zeile 3: 5 Sternchen ... Zeile n: ? Sternchen

Dass du nur Deutsch verstehst, hattest du nicht gesagt. Als angehender oder fertiger Fachinformatiker solltest du allerdings meiner Meinung nach schnellstens dafür sorgen, dass du mit englischer Dokumentation zurechtkommst. Es gibt einfach zuviel davon, als dass man sich dieser Informationsmenge verschließen sollte. Du warst es doch, der eine andere Frage als "dumm" bezeichnet hat. Darf man in einem Forum nicht etwas nachfragen?

Wer ist "er"? Zeile nimmt Werte zwischen 1 und 6 an. 11 ist niemals kleiner als einer dieser Werte, daher wird die innere Schleife immer übersprungen. Schreib doch mal in einer Tabelle auf, in welcher Zeile wieviele Sternchen ausgegeben werden sollen. Dann dürfte klarer werden, wie die innere Schleifenbedingung lauten muss.

Das dürfte daran liegen, dass 11<=zeile niemals wahr sein kann.

Auch nicht dümmer als Ich finde da jede Menge. Wonach hast du denn gesucht?

Die äußere Schleife ist in Ordnung. Deine innere Schleife macht aber in jeder Zeile dasselbe: Sie zählt in Zweierschritten von 1 bis 11. Du musst für die Steuerausdrücke der inneren Schleife einen Wert benutzen, der sich bei jedem Durchlauf der äußeren Schleife ändert.

Falsches Forum, Doppelposting. Bitte die Boardregeln beachten.

Verschoben -> Anwendungssoftware

Es ging mir nicht um Exceptions an sich, sondern um solche Konstrukte: try { if( !failing_function() ) throw x; } catch(...) { // Fehlerbehandlung }[/code]Hier ist die Exception nur ein besseres goto.

Schreib ein throw in den if-Block mit der Prüfung. Mal im Ernst, wozu? Exceptions sind für unvorhergesehene Situationen gedacht. Man kann sie für die Ablaufsteuerung benutzen, aber das ist eigentlich nicht Sinn der Sache. Da wirst du auf betriebssystemspezifische Funktionen zurückgreifen müssen, der C++-Standard deckt das nicht ab. Wenn du mit ... fängst, hast du keine Möglichkeit, an einen Fehlercode zu kommen. Außerdem fängt das keine Fehler wie Schutzverletzungen oder Division durch Null, außer bei gewissen nicht standardkonformen Compilern (MSVC). Auch dafür gibt es dann betriebssystemspezifische Funktionen. Die Exception-Basisklasse der C++-Standardbibliothek (std::exception) hat eine what-Methode, über die du einen Meldungstext bekommen kannst. Alle Exceptions der Standardbibliothek erben von dieser Klasse. Exceptions [C++ Reference]

Das ist allerdings etwas völlig anderes, als die bloße Frage, ob der Monitor ein- oder ausgeschaltet ist. Es gibt viele Möglichkeiten: Der Monitor zeigt nichts, weil er nicht mit Spannung versorgt wird, er ausgeschaltet ist, er im Standby ist, er defekt ist, kein Videokabel angeschlossen ist, die angeschlossene Grafikkarte nichts sendet, usw. Die meisten dieser Zustände lassen sich nicht durch Software allein prüfen. Darum zum wiederholten Mal die Frage, was und zu welchem Zweck du prüfen willst. Nach den aktuellen Informationen würde ich eher zu einem Strommessgerät an der Steckdose des Bildschirms raten.

Manchmal hilft da das Argument, dass man ja auch die alten Lochstreifen wieder rausholen könnte. Aber sei besser behutsam und überzeuge durch Ergebnisse. Ja, das kann unter Umständen sehr lange dauern. Manchmal bauen sich über die Jahre sehr große Scheuklappen auf. Gegen "Das haben wir schon immer so gemacht" ist kaum ein Kraut gewachsen. Deine Kollegen kennen das vermutlich nicht anders. Unlesbar ist das nur, wenn man es nicht gewohnt ist.

Mach deine Variablen so lokal wie möglich. Das ist nicht C, wo man alle Variablen am Anfang deklariert. Dann sollte das Problem verschwinden. Ich vermute die Ursache nämlich darin, dass du den Stringstream nicht zurücksetzt. Da steht noch der Operator von der vorhergehenden Zeile drin. Ich hatte dir auch vorher schon den Hinweis gegeben, dass du find und substr nicht brauchst. Deine Token-Suchschleife lässt sich stark vereinfachen: string gz; while (getline(csv, gz)){ string p, dn; int op = 0; istringstream line(gz); getline(line, p, ';'); getline(line, dn, ';'); line >> op; fc_action (op, dn, p + dn, log); // Löschen oder Kopieren } [/code] Ein paar Anmerkungen noch: Mehrere Flags verkettet man mit |, nicht mit Komma. Und c_str liefert niemals Null, die entsprechenden if-Abfragen sind also sinnlos. Falls der String leer ist, liefert c_str einen Zeiger auf einen leeren String. Wenn du eine rudimentäre Gültigkeitsprüfung machen willst, benutz std::string::length.

Du mischst immer noch .NET mit native DirectX. Du kannst als Callback keine .NET-Funktion benutzen, da hilft auch kein Cast. Fehlermeldungen enthalten auch nur selten "Korrekturvorschläge". Und ein Cast behebt nur sehr selten einen Compilerfehler. Üblicherweise handelt man sich damit nur einen Laufzeitfehler ein, der dann noch schwieriger zu beheben ist. Du könntest eine eigene Funktion in einem #pragma unmanaged-Block benutzen: managed, unmanaged Aber am einfachsten wäre es meiner Meinung nach, wenn du auf Managed DirectX umsteigst. Da brauchst du gar keinen Callback.

Falls das mit meinem vorherigen Beitrag nicht ganz klar wurde: Hier wären genaue Informationen hilfreich. Es gibt da ziemlich große Unterschiede zwischen beispielsweise VB6.0 und VB.NET 2008. Mit letzterem wärest du hier sogar im falschen Unterforum.

Mit C64-Basic geht das nicht. Aber vielleicht verwendest du ja etwas anderes...

Beim Kopieren öffnest du die Dateien in fc_action, und in fc_copyfile öffnest du sie nochmal. Das zweite Öffnen zum Schreiben dürfte fehlschlagen, daher klappt wohl das Kopieren nicht. Und beim Löschen öffnest du die Datei auch vorher. Eine geöffnete Datei kann man nicht löschen.

Natürlich musst du dann auch ein Stream-Objekt mitgeben. Ich meinte, beim Aufruf gibt es keinen sichtbaren Unterschied zwischen Value- und Referenzparametern. Zeig bitte den aktuellen Code. Remove hat immerhin einen Rückgabewert, den könntest du ausgeben. Und ob das Erstellen der Streams zum Kopieren geklappt hat, könntest du auch ausgeben.

Richtig. Streams können nicht kopiert werden, daher klappt das so nicht. Deklarier den ofstream-Parameter als Referenz: fc_action ( int op, string dn, string pad, ofstream& log ); Am Aufruf ändert sich nichts.

Du könntest versuchen, diese Mitarbeiter vorsichtig und höflich über RAII zu informieren.