Arbeiten mit dynamischer Speicherreservierung in "Dauerfeuerfunktionen"

  • C++

Es gibt 1 Antwort in diesem Thema. Der letzte Beitrag () ist von Takafusa.

    Arbeiten mit dynamischer Speicherreservierung in "Dauerfeuerfunktionen"

    Guten Abend zusammen,

    ich würde mich gerne über die Schnelligkeit und Sauberkeit lokaler, dynamisch allokierter Variablen informieren.
    Der Prozess des dynamischen Allokierens ist ja der, dass über den überladenen C++ Operator "new" letztlich mit (void*)malloc(size_t) neuer sequentieller Speicher gesammelt und die Adresse zurückgegeben wird, die auf die erste Sequenz des neu reservierten Speichers zeigt.

    Soweit so gut, ich frage mich, wie ressourcenintensiv dieser Prozess ist. Ich habe nämlich eine Funktion, die durchaus im "Dauerfeuer" ausgeführt werden kann. Es handelt sich um eine vererbte Funktion, die letzten Endes mit Win32-GUI-Operationen interagiert, was aber eigentlich keine Rolle spielen sollte. Ein Befehl allokiert in diesem Falle dynamisch. CreateSolidBrush erstellt mir immer wieder eine eine neue Adresse zu einem Brush-Handle mit einer RGB-Colorref.
    Ja, ich könnte diese Variable global erstellen und hätte damit nur einmal den genannten Befehl (CreateSolidBrush) ausgeführt. Nun habe ich aber in diversen Tutorials gelesen, dass man globale Variablen nach Möglichkeit vermeiden sollte. Und das ginge in diesem Falle auch. Am Anfang der Dauerfeuer-Funktion wird mit CreateSolidBrush(hBrush) irgendein Handle erzeugt und am Ende der Funktion mit DeleteObject(hBrush) wieder gelöscht. Die Vorgabe aus dem Tutorial wäre damit erfüllt. Ich hoffe, mir hauen jetzt nicht alle hier die halb verinnerlichte Vorgabe aus dem Tutorial um die Ohren :rolleyes: Ich finde das ganz logisch, dass man Variablen nicht global erstellen sollte, da die Gefahr groß sein könnte, dass man sie versehentlich irgendwo einbindet, wo sie gar nichts zu suchen hat. Ich könnte einer lokalen Variablen natürlich auch ein static-Schlüsselwort verpassen und ginge der Gefahr aus dem Weg. Initialisiert mit einem Speicherplatz im Heap wird eine static-Variable ja auch nur einmal.

    Wie soll man bei solchen Variablen vorgehen? Macht es was aus, wenn man einer Funktion, die pro Sekunde recht häufig ausgeführt wird (hab ich selbst einfach mal Dauerfeuer-Funktion genannt ;)), ständig im Heap neuen Speicherplatz zuweist und diesen nach der Benutzung vorschriftsgemäß (mit delete oder sonstigen Aufräumfunktionen) wieder an das System zurück gibt? Wie gesagt, dieser Prozess würde pro Sekunde mehrfach ausgeführt werden, sodass ich mich doch schon frage, wie sauber das ganze ist oder ob man hier davon absehen sollte, strikt auf eine lokale Variable zu beharren.

    Ich hoffe meine Frage kommt nicht zu doof rüber, ich ordne das mal als Anfängerfrage ein, da es um Speicherplatzverwaltung und Performance allgemein geht. So richtig kann ich das noch nicht einordnen bzw. da fehlen mir die Erfahrungen, wie ressourcenintensiv solche Befehle zum Allokieren sind.

    Vielen Dank vorab!
    Wenn du alles lokal in einer void machen kannst täte ich das tun. Solange du den reservierten Speicher wieder freigibst ist alles OK. Mehrmals pro Sekunde ist kein Problem, das geht so schnell, so schnell kannste nicht blinzeln. Aber m.M.n. sind Variablen auf Klassenebene auch Geschmackssache, solange sie private sind, kannst du sie nirgends anders nutzen als da wo sie sind/hingehöhren, nämlich in dieser Klasse. Braucht man eine variable nur in einer funktion, macht auf Klassenebene wenig Sinn, daher bleibt der Code aufgeräumter.

    Wer CPU instruktionen sparen will, kann schon einen Brush in der Klasse führen, im Konstruktor erstellen, im Destruktor freigeben, aber das macht den code schlechter lesbar wie auch schlechter verstehbar, weil man erstmal schauen muss wo welche Variable verwendet wird, was man nicht muss, wenn es in der funktion bleibt.
    Die Natur ist bekanntermaßen knallhart, sie sortiert aus was sich nicht bewährt hat.(Harald Lesch, 2021)

    Demnach müssten wir bald dran sein...

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Takafusa“ ()