3. delete(pointer) && globale Variablen

delete(pointer) && globale Variablen

  • ?

    Hallo,

    Ich habe mal die sources von supertux (Jmp'nRun) durchstöbert.
    Dabei sind mir 2 Sachen aufgefallen:

    void function(int *p)
{
    /* ... */

    delete(p);    // habe ich noch nie gesehen, oder gemacht
}

    und 2.:

    Im gesamten Code werden Massen von globalen Variablen genutzt. Mich wundert daß eigentlich alle Instanzen von Klassen GLOBAL auf dem Heap erzeugt werden.

    Daß sieht praktisch aus, ich will mir aber nichts falsches abgucken.

    0
  • ?

    Hört sich nicht gut an, modernes C++ sieht anders aus.

    0
  • N
     

    delete p;

    Damit gibt man den Speicherbereich frei, auf den der Zeiger p zeigt und der vorher mit new angefordert wurde. Klammern sind dabei eher unüblich, da delete ein Operator und keine Funktion ist. Allerdings ist das in deinem Fall nicht so gut gelöst, denn normalerweise überträgt man die Verantwortung zur Erstellung ( new , new[] ) und Löschung ( delete , delete[] ) dem gleichen Ort im Code, sonst hat man relativ schnell ein Durcheinander und riskiert Memory Leaks und doppelte Speicherfreigaben. In C++ kann man häufig auch bessere Möglichkeiten benutzen, z.B. Smart Pointer und Container.

    monde schrieb:

    Daß sieht praktisch aus, ich will mir aber nichts falsches abgucken.

    Ich finde es gut, dass du das so kritisch betrachtest. Denn du hast Recht dabei. Globale Variablen sind oft gefährlich und meistens ein Designfehler. Schau dir vielleicht auch diesen Thread an.

    Wenn man sorgfältig objektorientiert plant und auch eine genaue Vorstellung eines Konzeptes hat, sollte man globale Variablen in den meisten Fällen umgehen können und sauberere Wege finden. Jedoch sind sehr viele Programme, gerade Spiele, nicht wirklich schön programmiert, deshalb sollte man auch vorsichtig sein, wenn man deren Quelltext betrachtet.

    0
  • D

    Nexus schrieb:

    Jedoch sind sehr viele Programme, gerade Spiele, nicht wirklich schön programmiert, deshalb sollte man auch vorsichtig sein, wenn man deren Quelltext betrachtet.

    Absolut. Habe da sehr viel "Mist" gesehen. Die Spiele mögen sehr gut geworden sein, aber der Code ist vielfach einfach nur ein graus zum anschauen.

    Das Problem ist halt, dass gutes Design (gerade von Spielen) sehr schwer ist und man vieles durch nicht ganz koschere Methoden (globale vars, static usw.) löst, weil das um einiges einfacher ist und eigentlich auch gut funktioniert (wenn es nichts grösseres ist).

    Wenn dein Ziel guter Code ist, mach es nicht, wie du es oft siehst. Wenn du aber ein Spiel haben möchtest und da nicht die Zeit/Lust hast dir Design Gedanken zu machen, ist das ganze durchaus eine Möglichkeit.

    0
  • N

    drakon schrieb:

    Absolut. Habe da sehr viel "Mist" gesehen. Die Spiele mögen sehr gut geworden sein, aber der Code ist vielfach einfach nur ein graus zum anschauen.

    Ja, oft mag das mit den eigenen Kenntnissen zusammenhängen. Wenn man beginnt, Spiele zu programmieren, will man zuerst mal was sehen. Spielefeatures sollen vorhanden sein, über das Design kann man sich dann später Gedanken machen. Leider machen sich viele überhaupt nie Gedanken darüber, da Spiele halt nach Grafik, Sound, Gameplay bewertet werden und der Code dahinter niemanden interessert...

    Ich spreche aus eigener Erfahrung, und für mich ist die Umstellung auf sauberen Code zum Teil auch eine ziemliche Herausforderung. Aber zumindest versuch ich es. 🙂

    0
  • X

    Nexus schrieb:

    Globale Variablen sind oft gefährlich und meistens ein Designfehler. Schau dir vielleicht auch diesen Thread an.

    Die Frage die Du da stellst, kam mir auch öfter. Guter Link.

    Nexus schrieb:

    Wenn man beginnt, Spiele zu programmieren, will man zuerst mal was sehen. Spielefeatures sollen vorhanden sein, über das Design kann man sich dann später Gedanken machen. Leider machen sich viele überhaupt nie Gedanken darüber, da Spiele halt nach Grafik, Sound, Gameplay bewertet werden und der Code dahinter niemanden interessert...

    Schade, hab den Link vergessen, aber "als Anfänger" letztens gelesen, daß man als Einsteiger erst mal losprogrammieren sollte und dadurch im Laufe der Zeit erst lernt sinnvoll OOP zu betreiben. Da ist ein stückweit was wahres dran... Hätte ich sofort versucht mir erst mal Engines oder so etwas zu schaffen, hätte ich nach 2 Wochen vor lauter Unkenntnis aufgegeben. Der Weg ist das Ziel...

    0
  • N

    XHansWurstX schrieb:

    Schade, hab den Link vergessen, aber "als Anfänger" letztens gelesen, daß man als Einsteiger erst mal losprogrammieren sollte und dadurch im Laufe der Zeit erst lernt sinnvoll OOP zu betreiben. Da ist ein stückweit was wahres dran...

    Das will ich auch nicht bestreiten, jeder fängt mal so an. Man kann objektorientierte Programmierung nicht ohne Praxiserfahrung vollständig beherrschen. Das ist auch nicht schlimm, man sollte einfach mit der Zeit dran denken, sich weiterzuentwickeln... 😉

    Das Problem ist einfach, dass man häufig von sehr grossen Teilen von C++ noch keine Ahnung hat, was einem bei der Spieleprogrammierung oft Schwierigkeiten bereitet. Bei mir war es aufgrund nicht so guter Lehrmittel und meiner Ungeduld so, dass ich zu Beginn noch nicht sehr viel von Polymorphie, Templates, Operatorüberladung, STL, Zeigern und sonstigen elementaren Dingen gehört hatte. Das hatte dann entsprechende Auswirkungen beim Schreiben des Codes.

    0
  • X

    Nexus schrieb:

    Das Problem ist einfach, dass man häufig von sehr grossen Teilen von C++ noch keine Ahnung hat, was einem bei der Spieleprogrammierung oft Schwierigkeiten bereitet. Bei mir war es aufgrund nicht so guter Lehrmittel und meiner Ungeduld so,...

    Spricht mir aus der Seele...

    Nexus schrieb:

    Das ist auch nicht schlimm, man sollte einfach mit der Zeit dran denken, sich weiterzuentwickeln... 😉

    Dann schafft man es auch dank STL etc. alte Funktionen auf 1/3 o.ä. zu Kürzen oder in den digitalen Reißwolf zu schicken 😉

    0
  • N

    XHansWurstX schrieb:

    Dann schafft man es auch dank STL etc. alte Funktionen auf 1/3 o.ä. zu Kürzen oder in den digitalen Reißwolf zu schicken 😉

    Hehe, ja. Das ist dann wirklich eine Befriedigung, wenn man merkt, dass man nicht ein gigantisches verschwenderisches statisches Array anlegen muss, sondern die Möglichkeit hat, per Methodenaufrufe elegant Elemente an Container anzuhängen. 😉

    Oder auch (statische/dynamische) Polymorphie ist beeindruckend. Man erkennt, dass man nicht alles mehrfach schreiben muss, sondern nur einmal. Und trotzdem wird automatisch die richtige Implementierung ausgewählt.

    Jaja, mit der Zeit entwickelt man schon Freude an C++. 🙂

    0
  • X

    Nexus schrieb:

    Oder auch (statische/dynamische) Polymorphie ist beeindruckend. Man erkennt, dass man nicht alles mehrfach schreiben muss, sondern nur einmal. Und trotzdem wird automatisch die richtige Implementierung ausgewählt.

    Genau das habe ich viel zulange mißachtet und merke daß ich mir teilweise dadurch eher selbst Probleme geschaffen habe... Wie zB viel zu langer, unübersichtlicher doppeltdreifach Code. Naja, weiter geht's...on and on and on

    0
  • ?

    hab das pointer-delete gefunden/verstanden...

    header a...
void function_a()
{
    int *p =new int;
    function_b(p);
}
header b...
void function_b(int *p)
{
    /****/
    delete p;    // finde ich unübersichtlich, zumal der pointer in
                 // einem anderen header erstellt wird
}

    @nexus:
    ich habe deinen link gelesen und finde, die antworten teilweise nicht genügend begründet. besonders dein hinweis mit dem pointer, der ja auch überall geändert werden kann. da finde ich keinen unterschied zur globalen variable.

    0
Anmelden zum Antworten