Speicher am Heap in einer Funktion freigeben?
-
Ihr redet glaube ich aneinander vorbei.
Das Eingangsbeispiel mit dem new in einer Funktion war auch mit Uralt-C++ nicht gut.
Dafür hätte man sich halt -mangels STL- eine Klasse gebastelt (RAII), die dann tief unten drin auch irgendwann ein new/delete benötigt hätte.
-
@john-0 Ich glaube du verwechselst hier manuelle Resourcenverwaltung mit selbst geschriebenen RAII Klassen. Selbst geschriebene RAII Klassen braucht man sogar mit C++17 noch öfters, da es z.B. noch kein
unique_resourceTemplate in der Standard Libaray gibt, und nicht jeder "Resource-Identifier" ein Zeiger ist.Natürlich wäre es auch schön wenn man für so einfache Dinge wie "Socket Handle freigeben" keine eigenen Klassen mehr schreiben müsste. Der wichtigste Punkt ist aber dass man diese Klassen schreiben kann - und dann schön mit z.B. Sockets arbeiten kann ohne dass man an zig oder hunderten Stellen die Funktion zur Freigabe der Resourcen selbst aufrufen muss. Und das konnte C++ von Anfang an. Nicht so schön wie dann später mit Templates, aber es ging. Und das ist es was zumindest ich darunter verstehe wenn jemand schreibt "manuelle Ressourcenverwaltung von C loswerden".
-
@spiri sagte in Speicher am Heap in einer Funktion freigeben?:
Was aber bestätigt dass man vor der STL jedoch trotzdem das nackte new verwendet hat.
Und auch mit der STL verwendest du noch "nackte" Resource-Allokations-Funktionen irgendwo im Code. Idealerweise aber nur in einer Klasse, nämlich der RAII-Wrapper Klasse (oder einer Factory o.Ä.), aber selbst aufrufen tut man sie. Und das wird auch so bleiben, denn der C++ Standard wird nie sämtliche Arten von Resourcen abdecken die man von irgendwelchen (C-)Libraries bekommen kann.
-
@Swordfish sagte in Speicher am Heap in einer Funktion freigeben?:
Weder @SeppJ noch ich sind "C++ Crack"s. Aber wir wissen meistens, wovon wir reden. Wo du die Grenze zwischen modernem C++ und unmodernem ziehst ist mir herzlich schnuppe.
C++ ist eine historisch gewachsene Sprache, und viele der Paradigmen haben sich verändert. Man kann das ignorieren und mit aktuellen C++ exzellente Programme schreiben, aber dann darf man sich nicht wundern, wenn man viele Dinge die historisch gewachsen sind nicht versteht.
Es ist nun einmal eine Tatsache, dass an Universitäten die Uhren etwas anders gehen wie in der freien Wirtschaft. Deshalb ist es nicht sonderlich verwunderlich, wenn die Skripte nicht auf dem aktuellen Stand sind. Ferner sollte man als Student auch einmal die manuelle Speicherverwaltung gelernt haben, damit man zumindest in der Lage ist Klassen zu schreiben, die das korrekt umsetzen. Sprachen wie Python, Java, … sind dazu nicht geeignet, und wenn auch kein C mehr gelehrt wird, ist die Auswahl dafür gering. Es stellt sich also die Frage, ob der Dozent nicht absichtlich die manuelle Speicherverwaltung in C++ nutzt, damit die Studenten diese überhaupt kennenlernen.
Ist es daher sinnvoll immer wieder bei den hier anzutreffenden Fragen zur manuellen Speicherverwaltung darauf zu insistieren, dass std::vector und SmartPointer soviel besser in C++ seien und deshalb nur diese in Frage kämen?
Ohne Frage ist in der täglichen Nutzung von C++ für die normale Anwendungsentwicklung eine sehr weise Entscheidung zuerst Container aus der Standard Library zu nutzen, wenn diese nicht mehr ausreichen auf SmartPointer zu setzen und erst dann wenn diese Mittel nicht mehr ausreichend sind auf eigene Speicherverwaltung zu setzen. Aber auch für diesen speziellen gibt es sehr gute Gründe. Gerade weil das so ist muss man als Anfänger auch diese Sprachmittel erlernen.
Zum historischen Hintergrund
Es gab zwar schon in C with Classes Destrukturen, aber vieles was wir heute von C++ kennen gab es damals nicht. D.h. es gab keine Kopierkonstruktoren, keine Zuweisungsoperatoren (nur die C Zuweisung erfolgte, d.h. elementweise Kopie), d.h. RAII in seiner heutigen Form wurde erst später möglich. Stroustrup hatte zwar schon den Gedanken die Resourcenverwaltung zu verbessern, aber erst im Laufe der diversen Iterationen von C++ reifte dies zum dem heute Bekanntem heran. Mindestens das sollte man wissen.Desweiteren war der SmartPointer (std::auto_ptr<>) in der ISO Norm von 1998 kaputt, so dass er gar nicht benutzt werden konnte. Es gibt dazu etliche Artikel von Sutter, Meyers, et al. in denen sie die Defizite dieser Template Klasse beschreiben. Erst im Laufe der Jahre nach 1998 wurde im Boost Projekt funktionierende SmartPointer entwickelt. Aus den Erfahrungen mit denselben wurde dann eine leicht abgewandelte Variante Teil der ISO Norm von 2011. Ja, erst so spät gab es in der Norm funktionernde SmartPointer.
-
Es ist nun einmal eine Tatsache, dass an Universitäten die Uhren etwas anders gehen wie in der freien Wirtschaft.
Du hast eine falsche Vorstellung von der freien Wirtschaft.
-
@manni66 sagte in Speicher am Heap in einer Funktion freigeben?:
Du hast eine falsche Vorstellung von der freien Wirtschaft.
Ich denke nicht, an den Unis ist es zum Teil um Größenordnungen schlimmer. Ein Beispiel dazu. Ich hatte das Problem, dass ich von einem Professor Programmcode in Fortran77 bekam und darin ein Sprachkonstrukt aus Fortran66 (dieses Feature wird nur in alten Lehrbücher erklärt) verwendet wurde, dass bereits in Fortran77 als veraltet bezeichnet war. D.h. in einem Fortran77 Lehrbuch wird man dieses Feature nur finden, weil man es nicht nutzen soll. Die Pointe an der Geschichte das Programm ist komplett nach dem Jahr 2000 entstanden, und in der Zwischenzeit gab es Fortran90, Fortran95 und den neuen freien gfortran Compiler, d.h. keinerlei Grund mehr ein Fortran66 Sprachfeature zu nutzen.
P.S. Die BLAS und LAPACK Referenzimplementation ist noch immer in Fortran77 geschrieben.
-
@john-0
Ich habe an der Uni Java gelernt und das war zu einem Zeitpunkt, als man noch Probleme hatte, Bücher über dieses komische Java zu finden.Soviel zu deinen Verallgemeinerungen.
-
@Jockelx sagte in Speicher am Heap in einer Funktion freigeben?:
@john-0
Ich habe an der Uni Java gelernt und das war zu einem Zeitpunkt, als man noch Probleme hatte, Bücher über dieses komische Java zu finden.Und wie häufig wurde diese Vorlesung dann auf den aktuellen Java Stand angepasst?
-
@john-0 sagte in Speicher am Heap in einer Funktion freigeben?:
Und wie häufig wurde diese Vorlesung dann auf den aktuellen Java Stand angepasst?
Das weiß ich nicht. Das war aber auch eine Vorlesung, kein Programmierkurs. Letztere hab ich nie besucht, sind aber soweit ich weiß stets halbwegs aktuell gewesen.
Ist ja auch kein Wunder, wenn man jedes halbe Jahr von scratch anfangen kann. Und eben jenes nicht "von scratch anfangen" ist auch der Grund, warum das in der freien Wirtschaft meiner Erfahrung nach eben nicht so mega-innovativ zugeht (außer im Erfinden von innovativen Buzzwords).
-
@john-0 sagte in Speicher am Heap in einer Funktion freigeben?:
@Swordfish sagte in Speicher am Heap in einer Funktion freigeben?:
Weder @SeppJ noch ich sind "C++ Crack"s. Aber wir wissen meistens, wovon wir reden. Wo du die Grenze zwischen modernem C++ und unmodernem ziehst ist mir herzlich schnuppe.
[jede Menge dünpfiff]
Ich glaube du kannst nicht lesen!? Es ist mir wurscht.
-
@Swordfish sagte in Speicher am Heap in einer Funktion freigeben?:
Ich glaube du kannst nicht lesen!? Es ist mir wurscht.
Wozu sind Sie dann in einem Forum unterwegs, wenn sie an einem Meinungsaustausch keinerlei Interesse haben?
-
@john-0 sagte in Speicher am Heap in einer Funktion freigeben?:
Wozu sind Sie dann in einem Forum unterwegs, wenn sie an einem Meinungsaustausch keinerlei Interesse haben?
Kann ich dich auch fragen. Du hast nämlich auch ziemlich offensichtlich an Meinungs-austausch kein Interesse.
-
@Jockelx sagte in Speicher am Heap in einer Funktion freigeben?:
Das Eingangsbeispiel mit dem new in einer Funktion war auch mit Uralt-C++ nicht gut.
In C++ passiert aber alles in Funktionen. Ist da grundsätzlich was anders, nur weil wir denen speziellen Namen wie "Konstruktor", "Operator" oder "template Methode" geben?
-
@TGGC sagte in Speicher am Heap in einer Funktion freigeben?:
@Jockelx sagte in Speicher am Heap in einer Funktion freigeben?:
Das Eingangsbeispiel mit dem new in einer Funktion war auch mit Uralt-C++ nicht gut.
In C++ passiert aber alles in Funktionen. Ist da grundsätzlich was anders, nur weil wir denen speziellen Namen wie "Konstruktor", "Operator" oder "template Methode" geben?
Ja, da ist was grundsätzlich anders, wenn du den wichtigsten Name "Destruktor" in deine Aufzählung mit aufnimmst.
-
newin Desturktoren ist aber tendenziell eher selten
-
@hustbaer sagte in Speicher am Heap in einer Funktion freigeben?:
Kann ich dich auch fragen. Du hast nämlich auch ziemlich offensichtlich an Meinungs-austausch kein Interesse.
Wie kommen Sie zu diesem Schluss?
Ich habe hier nicht öffentlich bekundet, dass mich die Beiträge anderer Nutzer weder interessieren, noch diese herab gewürdigt.
-
@john-0 Naja du gehst kaum auf Antworten ein sondern wiederholst immer bloss deine Predigt. Das macht einfach nicht den Eindruck dass du ernsthaft an einem Meinungsaustausch interessiert wärst. Bzw. halt nur in der Richtung dass du predigst und (vermutlich) hoffst dass wir die frohe Botschaft dankend annehmen.
Und das ist halt uninteressant.Ich meine so ziemlich allen ist hier klar was SeppJ gemeint hat, und dass es stimmt. Du dagegen versteifst dich darauf seine Aussage anders zu interpretieren damit du predigen kannst.
Oder auch im anderen Thread wo du bloss immer wieder wiederholt hast dass "diese Einstellung zu Exploits führt" (sinngemäss) ohne auf irgendwelche Argumente einzugehen oder ein Beispiel zu geben wie in dem Konkreten Fall etwas schief gehen könnte. Das ist kein Meinungsaustausch, da hört sich einfach jemand gerne reden.
ps: Dass du hier fortwährend alle siezt, wo quasi alle anderen hier per-du schreiben, fügt sich auch schön in das Bild ein.
-
Dieser Beitrag wurde gelöscht!
-
@Swordfish
Lass mal gut sein, mit dem Offtopic. Hier und anderswo auch! @hustbaer redet sowieso nicht mehr mit dir und ich verstehe vollkommen warum.
-
@SeppJ sagte in Speicher am Heap in einer Funktion freigeben?:
@hustbaer redet sowieso nicht mehr mit dir und ich verstehe vollkommen warum.
Dann klär' mich bitte auf. Ich könnte mich nicht erinnern ihn irgendwo beleidigt oder schief angequatscht zu haben.
