namespace invader schrieb:
SeppJ schrieb:
Kennst du eine einzige (gute) Bibliothek bei der man das jemals so machen würde? Was meinst du, warum das nirgendwo gemacht wird? Die Verantwortung für Freigabe von Speicher überträgst du in sauberem Design nie.
In nahezu jeder API gibt es create_irgendwas-Funktionen, die dynamischen Speicher reservieren und dem Aufrufer abverlangen, eine entsprechende delete_irgendwas-Funktion aufzurufen, da er sonst ein Memory Leak baut.
Merkste was? Die rufen das create nicht selbstständig in einer Funktion auf und verlangen, dass der Benutzer das was aus der Funktion zurück kommt, einem delete_X vorwirft. Derjenige der das create_X benutzt hat, macht auch das delete.
fopen/fclose und diverse neue Funktionen aus threads.h sind letztendlich auch ein Beispiele dafür.
Gerade nicht. Siehe erklärung oben. Das fclose wird von dem gemacht, der fopen gemacht hat. Ebenso bei den Threads.
Wenn man über Modulgrenzen hinweg Speicher hin- und herreicht, wird man natürlich nicht einfach verlangen, ein rohes free() aufzurufen, sondern eine API-Funktion darum wrappen, insbesondere weil der Aufrufer gar nicht wissen soll was und wie dort für Speicher reserviert wird. Aber innerhalb eines kleinen Programms oder Moduls, zwischen Funktionen die zusammengehören, spricht nichts dagegen.
Also im Kleinen und bei Übungsbeispielen darf man schlampen? Damit erreicht man bloß, dass man. wenn es ernst wird, keine Ahnung hat, wie es richtig geht.
Als Alternativen guck dir an, wie das anderswo gehandhabt wird, ebenso meinen ersten Beitrag.
Du hast geschrieben dass Speicher immer in genau der selben Funktion wieder freigegeben werden soll, aber das ist im Allgemeinen nicht immer machbar und sinnvoll - dann bräuchte man ja beinahe gar kein malloc, sondern könnte einfach alles auf den Stack packen
Nein, ich schrieb, dass der Speicherreservierende den Speicher wieder freigibt. Das ist immer sinnvoll zu machen. Oben beschreibst du viele gute Beispiele, wie man das macht.
Ich halte es für verfehlt, jemandem, der erst dabei ist C zu lernen, gleich zu versuchen alle möglichen stilistischen Erwägungen einzutrichtern, denn den Sinn dahinter wird er ohnehin noch nicht verstehen können. Guck was pferdefreund aus deinem Tipp gemacht hat m(
Super. Da siehst mal, wo das hinführt, wenn man es nicht gleich von Anfang an richtig macht. Willst du, dass jeder endet wie die JW-Opfer?
Umgekehrt kommt man auf die meisten dieser Dinge von selbst, sobald man die Sprache kann und anfängt größere Programme damit zu schreiben; wer bei einem großen Programm merkt, dass er den Überblick über seinen dynamischen Speicher verliert, wird sich schon selbst Gedanken machen wie er ihn besser organisiert.
Da kommt man eben nicht so leicht von alleine drauf. Guck dir an, was der Threadersteller, du und pferdefreund getan haben. Und der Threadersteller hat eben gerade gefragt, weil er damit ein Problem hat.
Und natürlich sollte man einem Anfänger erklären, wie globale Variablen und longjmp funktionieren. Wie sonst soll er beurteilen können, wann und wann nicht es sinnvoll ist sie einzusetzen?
Zu der Erklärung was es tut gehört auch eine Erklärung, was da dran und warum gefährlich ist. Sonst ist die Erklärung nicht vollständig. Wenn jeder immer und immer wieder die gleichen Designfehler wiederholen soll, dann kann man sich die Lehre auch sparen und ihnen eine C-Referenz geben ganz ohne Erläuterungen.