3. Templates und deren Grenzen

Templates und deren Grenzen

  • B

    Wenn es nur einen Pointer und c gibt kann man auch einfach die Initialisierungsreihenfolge umdrehen. Dann wird aptr erst nach dem Konstruieren von c alloziert und du hast kein Speicherleck mehr.

    0
  • P

    Braunstein schrieb:

    Wenn es nur einen Pointer und c gibt kann man auch einfach die Initialisierungsreihenfolge umdrehen. Dann wird aptr erst nach dem Konstruieren von c alloziert und du hast kein Speicherleck mehr.

    Stimmt. Allerdings musst du dafür die Reihenfolge der Memberdeklarationen entsprechend ändern. Und wenn du ein paar Wochen später zu dem Schluss kommst dass da noch ein Member in die Klasse muss, hängst du den hinten ran, dessen Ctor schmeißt und - juhu. Wieder Speicherleck. Sowas macht man entweder richtig und robust oder man lässts gleich bleiben.

    0
  • D

    pumuckl schrieb:

    Braunstein schrieb:

    Wenn es nur einen Pointer und c gibt kann man auch einfach die Initialisierungsreihenfolge umdrehen. Dann wird aptr erst nach dem Konstruieren von c alloziert und du hast kein Speicherleck mehr.

    Stimmt. Allerdings musst du dafür die Reihenfolge der Memberdeklarationen entsprechend ändern. Und wenn du ein paar Wochen später zu dem Schluss kommst dass da noch ein Member in die Klasse muss, hängst du den hinten ran, dessen Ctor schmeißt und - juhu. Wieder Speicherleck. Sowas macht man entweder richtig und robust oder man lässts gleich bleiben.

    Naja. Das hast du bei deiner Variante 1 auch. Das "einzig" robuste, was man machen sollte, ist eine RAII Klasse zu benutzen. Dann hat man Ruhe.

    0

  • Hihi.
    Mal sehen wie lange es dauert bis auch in diesem Thread die alte RAII Debatte ausbricht 🙂
    *pfeiff, daumen dreh und wart*

    0
  • U

    pumuckl schrieb:

    B1() : aptr(0), c() 
  { 
    try { 
     aptr = new a(); 
    } 
    catch(...) 
    { /* delete alle pointer */ } 
  }

    Anders hab ichs doch nun auch nicht gemacht!?
    Jopp - das try / catch im CTor zusätzlich noch mal zu haben war vermutlich wirklich unnötig - also hab ich jz nur noch einen Funktions-Aufruf im CTor...

    bb

    0
  • N

    Wieso wird eigentlich immer shared_ptr als Smart Pointer vorgeschlagen? Je nachdem bietet er nur unnötige Funktionalität. Meines Erachtens hat er etwa den gleichen Status wie std::vector - einfach mal verwenden, solange man nichts Besseres weiss oder sich nicht darum kümmern will.

    Wenn die Klasse nicht kopiert oder zugewiesen werden muss, kann man auch scoped_ptr verwenden. Wenn bei Kopien oder Zuweisungen der Besitz übertragen werden soll, stellt auto_ptr eine Möglichkeit dar. Ich glaube zwar, die meisten hier wissen das, aber ich wollte es trotzdem mal erwähnen. 😉

    0

  • Was hast du denn gegen boost::shared_ptr bzw. std::vector?

    0
  • N

    hustbaer schrieb:

    Was hast du denn gegen boost::shared_ptr bzw. std::vector?

    Ich hab nichts gegen sie. Ich finde es nur ein wenig schade, dass sie immer als erstes und meistens auch als einziges erwähnt werden. Häufig habe ich das Gefühl, gerade bei std::vector , dass man ihn als Anfänger viel zu oft empfohlen bekommt. Selbst denkt man da nicht daran, dass es noch std::list für verkettete Listen oder std::tr1::array für statische Arrays gibt.

    Gleiches gilt für shared_ptr : Es ist nicht immer so, dass sich mehrere Instanzen einen Zeiger teilen müssen. Wenn man beispielsweise jede Instanz für sich verwaltet und von den anderen abgrenzt, ist scoped_ptr besser geeignet. Nicht nur wegen des Overheads; man sieht auch gerade, dass das Objekt nicht kopiert werden kann. Bei shared_ptr hingegen ist die Gefahr grösser, dass man normal kopiert, sich aber später fragt, warum hinter den beiden Zeigern das gleiche Objekt steht.

    Naja, das Ganze ist vielleicht ein bisschen weit hergeholt, aber bei mir war es so, dass ich am Anfang kaum Ahnung von STL hatte und einfach immer std::vector statt C-Arrays benutzte (ohne Iteratoren). Mir standen deswegen auch weniger Möglichkeiten offen. Klar, wenn man sich wirklich interessiert, liest man sich auch mehr zur Thematik ein. Trotzdem halte ich es nicht für falsch, die Alternativen auch noch aufzuzählen. 😉

    0

  • Hm. OK.
    Ich empfehle shared_ptr und vector weil es die beiden Kandidaten sind die ich zu 90% (mehr wahrscheinlich) verwende.
    Und wozu die Kids verwirren wenn sie's vermutlich eh kaum jemals brauchen werden?

    Und natürlich sollte jeder der sich Programmierer nennen will selbst nachgucken was es so alles in der Standard-Library gibt, bzw. in wirklich bekannten Libraries wie Boost.

    0
  • D

    hustbaer schrieb:

    Hm. OK.
    Ich empfehle shared_ptr und vector weil es die beiden Kandidaten sind die ich zu 90% (mehr wahrscheinlich) verwende.
    Und wozu die Kids verwirren wenn sie's vermutlich eh kaum jemals brauchen werden?

    Und natürlich sollte jeder der sich Programmierer nennen will selbst nachgucken was es so alles in der Standard-Library gibt, bzw. in wirklich bekannten Libraries wie Boost.

    Genau. Und der Vorteil ist, dass, wenn du shared_ptr/std::vector empfiehlst, dann kommt das wahrscheinlich am nächsten zu dem, was die Anfänger überhaupt suchen. Ansonsten kommen dann so Fragen, wie "warum geht das nicht und warum kann ich nicht das und das machen?". Und dann gibts du ihnen so, oder so diese Varianten..

    0

  • Genau 🙂
    Allerdings muss ich was ich geschrieben habe doch etwas relativieren *g*. Wenn ich den Eindruck habe dass jmd. damit jetzt nicht total überfordert ist, dann finde ich es schon OK darauf hinzuweisen dass es auch andere Container bzw. Smart-Pointer gibt, die für bestimmte Fälle besser geeignet sind.

    Allerdings bin ich meist einfach zu faul. Und ich sehe es auch nicht als Aufgabe eines Forums jmd. einen Überblick über die Features einer Library oder Programmiersprache zu geben - dafür gibt es Referenz-Dokus, Tutorials und Lehrbücher 🙂

    0
Anmelden zum Antworten