Hallo, könnte jemand von euch mir meinen Code über Valgrind oder Splint oder ähnliches laufen lassen und mir die Fehlermeldungen ausgeben? Weiß nicht so recht wie das geht... Bei meinem Code stürzt das Programm nämlich dann ab, wenn es return 0; erreicht. Ich weiß ist im Moment echt schlecht geschrieben, ist eher nur zu Testzwecken programmiert. MfG
:
Bearbeitet durch User
Also wenn ich schon Code sehe, der "goto" für was anderes als Fehlerbehandlung verwendet, und wo nichtmal die Einrückungen sinnvoll gesetzt sind, und wo bei calloc nicht auf Nullpointer gecheckt wird, dann wundert mich ein Crash nicht. Das ist selbst zu "Testzwecken" dermaßen schlecht geschrieben, daß hier ursächlich ein Layer-8-Problem vorliegt. Kein Wunder, daß Du Dich in Deinem chaotischen Spaghettizeug nicht zurechtfindest. Davon ab meldet CppCheck für Zeile 40: fflush() called on input stream 'stdin' may result in undefined behaviour on non-linux systems.
Erstens: Valgrind funktioniert so, dass man statt "./programm" einfach "valgrind ./programm" startet. Splint lässt man eher auf den Quelltext los. Zweitens: Wenn du Scheiße programmieren möchtest, dann musst du auch Scheiße debuggen können. Mach es lieber gleich richtig, dann hast du später weniger Stress. Drittens: Wenn du viel mit Strings hantierst und Geschwindigkeit eher nebensächlich ist, dann sind Scriptsprachen evtl. besser geeignet als C.
S. R. schrieb: > Drittens: Wenn du viel mit Strings hantierst und Geschwindigkeit eher > nebensächlich ist, dann sind Scriptsprachen evtl. besser geeignet als C. Ich würde auch Pascal empfehlen. Zwar ist das wie Radfahren mit Stützrädern, aber es läßt ziemlich viel Unsinn gar nicht erst zu, was bei dem unterirdischen Codingniveau eine große Hilfe wäre.
pz = Primzahl? Also ein Sieb des Eratosthenes? Dafür gibt es doch schon unzählige Lösungen im Web. Ne, mal ehrlich. Vielleicht sollte man den Variablen vernünftige Namen geben. Und auch mal kommentieren was Zeilen wie if(strlen(BN)<=9 && strlen(BN)>=7) strcpy(Benutzername[j],BN); bezwecken sollen. Normalerweise werden Grossbuchstaben-Identifier wie BN für Makros und defines benutzt. Debug einfach dein Programm mal selber. Dann ist der Lerneffekt am höchsten.
PittyJ schrieb: > Debug einfach dein Programm mal selber. Dann ist der Lerneffekt am > höchsten. Der Lerneffekt dürfte dann auch zum Verständnis eines bekannten Zitats von Kerninghan beitragen: Es ist allgemein bekannt, daß Debuggen doppelt so schwierig ist wie ein Programm überhaupt zu schreiben. Wenn man also den Code so clever schreibt, wie man kann, wie soll man das jemals debuggen?
Du solltest damit anfangen die Rueckgabewerte von calloc zu pruefen... Von deiner verwendung von goto reden wir erst gar nicht...
Nop schrieb: > Der Lerneffekt Ich frage mich zunächst, was sich der Lehrer bei der Aufgabe gedacht hat. So eine Anwendung in C zu schreiben ist doch nun wirklich kein Vergnügen -- und damit ist der ausbleibende Lerneffekt doch schon programmiert. C mag auch für Anfänger ein sinnvoller Einstieg sein, aber dann muss man sich eben auf den Algorithmus als solchen konzentrieren, und sich nicht zunächt mit Trivalitäten wie Speicher-Allozierung konzentrieren. So ist doch klar, dass die Kinder C gleich als eklig empfinden werden und sich dann auf Webdesign mit Java-Script freuen, oder eben von Informatik ganz die Finger lassen. (Und klar ist Speicher-Allozierung und Debugging extrem wichtig, wenn man dann tatsächlich später beruflich mit C arbeitet.)
Der code ist ja so richtig sch.... Fängt auch schon gut an:
1 | char **Benutzername, |
2 | char **Passwort; |
3 | |
4 | Benutzername=calloc(100,1); |
5 | Passwort=calloc(100,1); |
Meep, falsch. Sollte nämlich besser calloc(100, sizeof(char*)) heissen, so wird nur 1/4 oder 1/8 des benötigten Speichers allokiert. Damit hast Du hier:
1 | for(i=0;i<100;i++){ |
2 | Benutzername[i]=calloc(20,1); |
3 | Passwort[i]=calloc(20,1); |
4 | }
|
einen fiesen Heap-überlauf. Der knallt hier nicht sofort, sondern erst unten beim free() Aufruf. Den Rest schenke ich mir, da werden sicher noch mehr Fehler drin sein.
Stefan S. schrieb: > Ich frage mich zunächst, was sich der Lehrer bei der Aufgabe gedacht > hat. Ja, daß es sich dabei um den Versuch einer Hausaufgabe handelt, die mit "Testzwecken" nichts zu tun hat, ist offensichtlich. Angesichts dessen, wie das runtergerotzt ist, bezweifle ich, daß das so gefordert war. Sieht mir eher aus, als sei das Semester fortgeschritten, der TO hat den Anschluß verloren, und jetzt funktioniert "es irgendwie halbverstanden runterhacken" nicht mehr. Wenn ich mich an meinen C-Kurs in der Uni entsinne, die Vorlesung fand ich dermaßen schlecht, daß ich mir nur die Übungsblätter für den Hausaufgabenschein rausgeholt habe und dann eigenständig mit nem C-Lehrbuch gearbeitet habe. > So ist > doch klar, dass die Kinder C gleich als eklig empfinden werden Falls es sich um einen Programmierkurs an der Uni handelt, kann das durchaus Absicht sein, und zurecht: https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/ "All the kids who did great in high school writing pong games in BASIC for their Apple II would get to college, take CompSci 101, a data structures course, and when they hit the pointers business their brains would just totally explode, and the next thing you knew, they were majoring in Political Science because law school seemed like a better idea. I’ve seen all kinds of figures for drop-out rates in CS and they’re usually between 40% and 70%. The universities tend to see this as a waste; I think it’s just a necessary culling of the people who aren’t going to be happy or successful in programming careers."
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.