Klotzkopp

Was soll das sein? Meinst du vielleicht CI?

Mit delete[] gibst du frei, was du mit new[] angefordert hast. Das gibt's nur in C++. Mit free gibst du frei, was du mit malloc angefordert hast. Das gibt's in C und in C++.

Gar nicht. Du kannst zweidimensionale Arrays nicht dynamisch anlegen, also brauchst du sie auch nicht zu löschen. Was du dynamisch anlegen kannst, sind Zeiger-Arrays, bei denen wiederum jeder Zeiger auf ein eigenes Array zeigt. Das fühlt sich in der Benutzung so an wie ein 2D-Array, aber es ist nach wie vor eine Menge von 1D-Arrays, die du genau wie sonst auch behandeln kannst. Wenn du für jeden einzelnen Zeiger in deinem Zeiger-Array Speicher geholt hast, musst du auch jeden einzelnen Zeiger wieder freigeben. Zu jedem malloc gehört ein free.

Was hat Read-only mit Verstecken zu tun?

Vom ReadOnly-Attribut eines Ordners sollte man normalerweise die Finger lassen. Die darunterliegende WinAPI-Funktion erlaubt das auch nicht. Was willst du denn damit erreichen?

Das sollte auch für Ordner funktionieren.

Hostanzahl = (2 hoch (32 - Präfix)) - 2

Warum? Du zwingst damit jeden Benutzer deines Headers, diese Header selbst einzubinden. Du sparst nichts dadurch, und erzeugst zusätzliche Arbeit für den Benutzer deiner Klasse. LError.cpp ist uninteressant. Der Fehler entsteht doch gar nicht beim Compilieren von LError.cpp, sondern von der .cpp-Datei, in der die Klasse benutzt werden soll. Zusammenfassung: Lass es. Die Includedirektiven gehören da hin.

fgets kann nicht, was du willst. Ich sehe da (zumindest in C) nur zwei Möglichkeiten: Zeichenweise einlesenDie ganze Zeile einlesen und hinterher den eingelesenen String zerlegen

Wahrscheinlich daran, dass du sie nach dem Zugriff nicht wieder ordentlich geschlossen hast. Geöffnete Dateien kann man in der Regel nicht löschen. DeleteFile ist übrigens eine WinAPI-Funktion. Wenn du portabel bleiben willst, benutz std::remove.

Steckt da irgendeine Planung dahinter, oder ist der Code durch Ausprobieren entstanden? Wenn du nicht weißt, wo und warum es hängt, wie kannst du dann beurteilen, was "unwichtig" ist und daher weggelassen werden kann?

Lass den Rückgabewert weg, du brauchst ihn nicht und benutzt ihn auch nicht: void eingabe(char *s,size_t w) { fgets( s,w,stdin ); }[/code]

Hier passt's schon nicht. Du möchtest, dass die Funktion ein char-Array zurückgibt, deklarierst den Rückgabetype aber als einzelnes char. Arrays sind in C nicht kopierbar. Du kannst einem Array nichts zuweisen, und du kannst es daher auch nicht als Rückgabetype benutzen. Die übliche Lösung ist, das Array als der Funktion als Parameter mitzugeben: Allerdings können Arrays auch keine Funktionsparameter sein. Sie degenerieren dann zu Zeigern auf das erste Element. Das hat zur Folge, dass die Information, wie groß das Array ist, verloren geht. Wenn du diese Information brauchst, solltest du sie in einem zusätzlichen Parameter mitgeben.

Wie flashpixx schon sagte: Wenn hier der Klasse-Konstruktor eine Exception wirft, kommt es nie zum Aufruf von test(). Exceptions sind genau dafür da, damit du deinen Code nicht mehr mit solchen Prüfung zupflastern musst. new gibt niemals NULL zurück. new wirft eine Exception, wenn nicht genug Speicher da ist. Das ist C-Style, genau wie die Nullinitialisierung mit nachfolgender Neuzuweisung. Das ist doch das Schöne an Exceptions: Wenn der Konstruktor ordentlich implementiert ist, also eine Exception wirft, wenn was nicht klappt, dann kannst du, wenn das Programm nach diesem new weiterläuft, davon ausgehen, dass alles geklappt hat. Es war genug Speicher da, und das Objekt konnte fehlerfrei erstellt werden. Du brauchst an dieser Stelle dann keine Gültigkeitsprüfung. Ein sauber aufgezogenes C++-Programm sieht immer ein wenig aus wie "Schönwetterprogrammierung". Man geht davon aus, dass alles klappt. Wenn was nicht klappt, fliegt eine Exception, die an geeigneter Stelle behandelt wird. Exceptions bieten die Möglichkeit, die Fehlerbehandlung von der Programmlogik zu trennen. Ansonsten gibt das einen heillosen Mischmasch aus Code, der etwas tut, und Code, der nur dazu da ist, zu prüfen, ob alles geklappt hat.

Die Includedirektive für den vorkompilierten Header (normalerweise stdafx.h) gehört in die .cpp-Datei, und sie muss die erste Includedirektive in der Datei sein. Alle Includedirektiven, die davor stehen, ignoriert der Compiler. Und Hexagon hat Recht: using-Direktiven gehören nicht in Headerdateien. Ansonsten kann sich das Verhalten einer .cpp-Datei komplett ändern, wenn man einen zusätzlichen Header einbindet, weil plötzlich ganz andere Funktionen in die Überladungsauflösung einbezogen werden.

Zeig doch mal, wie der Code jetzt aussieht.

Abgesehen davon ist auch die Summenfunktion falsch. Was soll das if da?

Woher stammen denn diese kaputten Werte? Zeigt die der Debugger an? In der Release-Konfiguration ist Debuggen nicht immer verlässlich. Tut das Programm denn ansonsten, was es soll? Wenn i größer als 3 wird, erzeugt der Zugriff auf buffer undefiniertes Verhalten. Wenn i kleiner als 3 bleibt, erzeugt der nachfolgende Zugriff auf buffer mit atoi undefiniertes Verhalten, weil nie etwas in buffer reingeschrieben wurde. Du verlässt dich hier einfach darauf, dass das Einlesen aus der Datei klappt und dass die Daten genau das Format haben, das du erwartest.

Der Fehler liegt in der Regel nicht an der Stelle, an der er sich bemerkbar macht. Wenn du dir irgendwo den Stack oder den Heap zerschießt, merkst du das möglicherweise erst viel später, an einer Stelle, die damit gar nichts zu tun hat. Dein Code ist sehr anfällig für Pufferüberläufe und Indexüberschreitungen. Die Klassen der C++-Standardbibliothek könnten dich da schützen, aber du benutzt überwiegend Funktionen, die aus C stammen. Der Code sieht eher wie "C mit Klassen" aus, nicht wie C++. An etlichen Stellen fehlen Fehlerbehandlung und Sicherheitsprüfungen. Du prüfst beispielsweise nicht, ob fopen erfolgreich war. In der strtok-Schleife stellst du nicht sicher, dass i nicht zu groß wird. Prüf die Rückgabewerte von Funktionen, die fehlschlagen können. Und prüf bei jedem Array-Zugriff, ob der Index im gültigen Bereich ist. Nicht nur in dieser Funktion, sondern im ganzen Programm.

Wenn etwas in der Debug-Konfiguration funktioniert, aber als Release nicht mehr, ist der Grund fast immer schlampige Programmierung. Die Ursachen können vielfältig sein. Bereichsüberschreitungen bei Arrays, uninitialisierte Variablen, fehlende Threadsynchronisierung. Allgemein alles, was undefiniertes Verhalten erzeugen kann. Kompiliert dein Code ohne Warnungen?

Ich sagte zwei Elemente. Arrays mit einem Element lösen das Problem nicht.

Wenn du bei %1s bleibst, musst du aus deinen Eingabevariablen char-Arrays mit 2 Elementen machen, sonst erzeugt der Code undefiniertes Verhalten.

Erzeug die Passwörter zunächst ohne Ziffern in der passenden Länge, und häng dann die Ziffern hinten dran. Beispiel: Wenn die Länge 8 sein soll, dann erzeuge 8-3=5 Zufallszeichen und häng 3 Zufallsziffern an.

Mit diesem Code tritt das Problem bei mir nicht mehr auf. Allerdings hast du noch einen Fehler beim Einlesen der Benutzereingaben: Wenn du mit %1s einliest, brauchst du ein char-Array mit mindestens zwei Elementen, weil automatisch eine Nullterminierung angehängt wird. Alternativ kannst du auch mit %c einlesen.