3. speicherleak

speicherleak

  • T

    Bei C++ solltest du soweit es geht auf reine Zeiger verzichten.

    Nur besitzende reine Zeiger. Als Verweis dürfen die immer noch in Gebrauch sein.

    0
  • Mod

    DarkShadow44 schrieb:

    Bei C++ solltest du soweit es geht auf reine Zeiger verzichten. Und wenn setz den Zeiger auf 0 wenn er auf nichts mehr zeigt.
    Ich vermute "this->_d1" wird doppelt freigegeben.

    Ich denke, das ist kein guter Ratschlag, mit dem Nullsetzen. Das verhindert zwar eine eventuelle doppelte Freigabe, aber der eigentliche Fehler ist, dass es überhaupt dazu kommen kann. In "richtigem" C++ programmiert man so, dass dies gar nicht möglich ist. Diese Techniken sollte er lernen. Nicht, wie man den Fehler, den er hier hat, vertuscht.

    0
  • Mod

    Ich denke, das ist kein guter Ratschlag, mit dem Nullsetzen.

    Das hängt vom Kontext ab.

    Natürlich nicht im Destruktor. Aber die Pauschalaussage, "setz den Zeiger auf 0 wenn er auf nichts mehr zeigt", ist doch deines Erachtens nach nicht etwa falsch. Wenn ich einen Zeiger als Member halte, dann ist es völlig selbstredend, dass 0 den ungültigen Zustand beschreibt.

    0
  • Mod

    • schrieb:

    Ich denke, das ist kein guter Ratschlag, mit dem Nullsetzen.

    Das hängt vom Kontext ab.

    Natürlich nicht im Destruktor. Aber die Pauschalaussage, "setz den Zeiger auf 0 wenn er auf nichts mehr zeigt", ist doch deines Erachtens nach nicht etwa falsch. Wenn ich einen Zeiger als Member halte, dann ist es völlig selbstredend, dass 0 den ungültigen Zustand beschreibt.

    Nicht pauschal, aber hier ist einer der Kontexte, wo es tatsächlich ganz gezielt der Fehlervertuschung dienen soll. Falls double-free das Problem ist, dann ist das Problem, dass da etwas freigegeben werden soll, was nicht freigegeben werden darf. Da ist die Lösung nicht, dass man vor der Freigabe prüft, ob man wirklich darf, sondern dass man erforscht, wieso es überhaupt zu diesem Fehler kommen konnte. Denn da ist ein Logikfehler im Code. Denn hier wird ja anscheinend angenommen, dass ein gewisses Objekt noch existiert, obwohl es vorher schon freigegeben wurde. Wo ein solcher Fehler ist, da sind andere (z.B. Zugriff auf den schon freigegebenen Bereich) nicht weit. Das muss man beheben, nicht Augen und Ohren verschließen.

    (Wirklich richtig wäre natürlich, RAII zu benutzen, damit so etwas gar nicht erst vorkommen kann)

    0
  • ?

    hm okay, kann mir vielleicht jemand sagen wie man einen vector von bools machen kann, ohne dass da die template-spezialsierung verwendet wird?

    0
  • S

    Was hast du denn vor?

    Zur Not schreibst du dir eine eigene Klasse, die einen bool einkapselt, aber sämtliche möglichen Operationen anbietet. Das ist viel Arbeit, nicht wirklich effizient und auch fehleranfällig.

    Daher: die Frage von oben...

    0
  • ?

    eine zugriffsfunktion die eine nicht-konstante referenz auf einen bool zurückgibt (also aus dem entsprechenden vector den richtigen bool raussucht und als veränderbare referenz dem aufrufer gibt).

    compilerausgabe:

    main.cpp:1051:48: error: invalid initialization of non-const reference of type 'bool&' from an rvalue of type 'std::vector<bool>::reference {aka std::_Bit_reference}'

    edit:
    wird das problem behoben und das korrekte verhalten immitiert wenn ich als rückgabewert "::std::vector<bool>::reference" statt "bool&" nehme?

    0
  • Mod

    igno schrieb:

    edit:
    wird das problem behoben und das korrekte verhalten immitiert wenn ich als rückgabewert "::std::vector<bool>::reference" statt "bool&" nehme?

    Ja, aber einfacher wäre, einfach vector char zu nehmen. Auf jeden Fall ist es keine gute Idee, selber den vector nach zu programmieren. Und wenn doch, dann auch wirklich nachprogrammieren, keine manuelle Speicherverwaltung.

    0
  • ?

    SeppJ schrieb:

    igno schrieb:

    edit:
    wird das problem behoben und das korrekte verhalten immitiert wenn ich als rückgabewert "::std::vector<bool>::reference" statt "bool&" nehme?

    Ja, aber einfacher wäre, einfach vector char zu nehmen. Auf jeden Fall ist es keine gute Idee, selber den vector nach zu programmieren. Und wenn doch, dann auch wirklich nachprogrammieren, keine manuelle Speicherverwaltung.

    mein ziel ist es ja nicht wirklich einen vector nachzuprogrammieren. ich hab den quellcode ja nun überarbeitet und es wird intern in meiner klasse nun std::vector verwendet. solche getter usw brauche ich aber dennoch weil die indices nunmal nicht - wie beim vector - von 0 .. size()-1 laufen.
    das problem dürfte nun behoben sein, danke für eure hilfe.

    0
  • Mod

    Falls du es noch wissen willst: Du kannst festlegen, dass das Template nicht Spezialisiert werden soll. Mit dem Makro STD_VECTOR_BOOL_NOT_SPECIAL .

    0
Anmelden zum Antworten