"Die Anweisung in 0xblablabla verweist auf Speicher in 0xblablabla. Der Vorgang konnte nicht auf dem Speicher durchgeführt werden."

Führe ich das Programm im Debug-Modus aus, so kommt am Ende die Meldung:

"An Access Violation (Segmentation Fault) raised in your Program."

Ich weiß, dass hier keiner hellsehen kann und mir den Fehler sagen kann. Mir geht's darum, mit welcher ART von Fehler diese Meldungen zusammenhängen können.

Ich gehe davon aus, dass wohl irgendein Zeiger auf eine unerlaubte Adresse zeigt?

Mein Programm verwendet einige Zeiger; obwohl ich mich eigentlich immer bemüht habe, alles aufzuräumen: Klassen mit Zeiger haben entsprechende Destruktoren, kein new ohne delete. Dass ich trotzdem irgendwo was falsch gemacht habe, kann ich natürlich nicht aussschließen (ich gehe sogar davon aus...)

Aber die Frage ist: Warum läuft das Programm scheinbar erstmal normal durch, warum kracht es erst beim Beenden?

Ich gehe davon aus, dass wohl irgendein Zeiger auf eine unerlaubte Adresse zeigt?

Das Zeigen alleine reicht noch nicht. Erst wenn ein wilder Pointer dereferenziert wird kracht es.

sly schrieb:

Aber die Frage ist: Warum läuft das Programm scheinbar erstmal normal durch, warum kracht es erst beim Beenden?

Vielleicht ein delete zuviel?

Aber wie bereits gesagt:

sly schrieb:

Ich weiß, dass hier keiner hellsehen kann und mir den Fehler sagen kann.

Aber die Frage ist: Warum läuft das Programm scheinbar erstmal normal durch, warum kracht es erst beim Beenden?

Weil's vielleicht in irgend'nem Destruktor knallt?
Irgendwelche Objekte in der main, static Objekte? Da würd ich mal nachschauen.

1. spielt die Reihenfolge der delete's eine Rolle? (also ich meine wenn ich am Ende der main() jeden mit new angeforderten Speicher freigebe)

2. Es existiere folgender Code:

//A.h
#include "B.h"
class A
{
   public:
      A() {}
      void doSomething(B* b)
      {
         //alle auskommentierten Zeilen für Fall 4 (siehe unten)
         //b = new B;
          b->whatEver();
         //delete b;
      }
};

-> was ist besser/wo liegt der Unterschied zwischen folgenden Aufrufen:

#include "A.h"
#include "B.h"
int main()
{   
    A a;
    //Fall 1:
    a.doSomething(new B);

    //Fall 2:
    B b2;
    a.doSomething(&b2);

    //Fall 3:
    B* b3 = new B;
    a.doSomething(b3)
    delete b3;

    //Fall 4:
    B* b4;
    a.doSomething(b4);

}

Was passiert in Fall 1? Eigentlich wird ja dort auch mit new neuer Speicher angefordert, aber eben über ein temporäres Objekt? Aber wer gibt den Speicher wieder frei??

Viele Fragen, ich hoffe auf viele Antworten.

1. spielt die Reihenfolge der delete's eine Rolle? (also ich meine wenn ich am Ende der main() jeden mit new angeforderten Speicher freigebe)

Nur bei voneinander abhängigen Objekten (und das sollte man dann anders lösen ;))

Was passiert in Fall 1? Eigentlich wird ja dort auch mit new neuer Speicher angefordert, aber eben über ein temporäres Objekt? Aber wer gibt den Speicher wieder frei??

Niemand, das nennt man dann Speicherleck

In Fall 2 ist das Objekt ein gültiges Objekt auf dem Stack von main, in Fall 3 ein gültiges Objekt auf dem Heap.

Fall 4 ist undefiniert, da b4 nicht auf ein gültiges Objekt zeigt.

zu 2)
Fall 1 ist schlecht, da du, wie bereits scholn gesagt hast, niemand den speicher freigibt. Das müsste dann in der funktion doSomething gemacht werden, was aber echt schlehct wäre, da danach das objekt nicht mehr nutzbar ist, falls man es anderweitig übergtibt. Außerdem gäbe es eine zugriffsverletzung, wenn du versuchst, ein objekt das auf dem stack liegt zu löschen.

Fall 2: Ist in diesem kontext wohl die beste Lösung, solagne B nicht allzu viel speicher auf dem stack anlegt. du übergibst Dosomething die Adresse, und da wird dann wa mit gemacht. So is das shcon ganz gut. Du könntest aber auch eine Referenz übergeben, manche machen das lieber so, is meiner meinung nach auch besserer Stil alsdie Adressübergabe.

Fall 3: Macht man so, wenn B ein sehr großes Objekt ist, was nicht auf den Stack passt. Oder man macht es, wenn man b noch außerhalb des scopes benötigt indem es erstellt wurde. Sieht mir nich so aus, also in dem fall auch nich anzuraten.

Fall 4 ist totaler Müll Da du einbfach einen Zeiger übergibts der irgendwohin zeigt und nicht auf ein fertiges B, sieht das im code schonmal echt scheiße aus Wieterhin wird das Objekt dann in DoSomething erstellt, danmit wird was gemacht und dann wird es wieder gelöscht. Wozu übergibts du dann überhaupt einen Zeiger als parameter? Den brauchst du gar nich, DoSomething kann den Zeiger auch lokal speichern.

Also, Fall 2 und Fall 3 is OK, der rest nich so. fall 1 möglicherweise noch, wenn du Objekte hast, die sich im Konstruktor bei einer Managerklasse registrieren und dann von dieser gelöscht werden.

Nur bei voneinander abhängigen Objekten (und das sollte man dann anders lösen )

Wie?

Also angenommen es gibt zwei Klassen A und B, A besitze als Membervariable einen Zeiger auf ein Objekt der Klasse B.

Objekte der Klassen A und B werden jeweils in main() mit new angelegt und wieder mit delete freigegeben. Ist das schlecht?

Fall 1 ist schlecht, da du, wie bereits scholn gesagt hast, niemand den speicher freigibt. Das müsste dann in der funktion doSomething gemacht werden

WIE müsste ich das machen? Wie kann ich auf das Objekt überhaupt zugreifen? (es wurde ja kein Bezeichner eingeführt..)

Du könntest aber auch eine Referenz übergeben, manche machen das lieber so, is meiner meinung nach auch besserer Stil alsdie Adressübergabe.

So?

void doSomething(B& b)
      {
         b.whatEver();
      }

#include "A.h"
#include "B.h"
int main()
{   
    A a;
    B b;
    a.doSomething(b);

}

Fall 4 ist totaler Müll

Das war deutlich. Scheiße sieht es wohl wirklich im Code aus und unsinnig ist es wahrscheinlich auch.

Kannst mir aber nochmal genauer erklären, warum es speichertechnisch nicht korrekt ist?

Ok, ich übergebe einen undefinierten Zeiger, aber in der Methode wird ja dann mit new ein gültiges Objekt erzeugt und brav wieder freigegeben.

Ist sowas nicht erlaubt? Einen Zeiger übergeben, der erstmal nirgendwo hinzeigt und erst in der Methode dann auf ein Objekt gerichtet wird?

Wie?
Also angenommen es gibt zwei Klassen A und B, A besitze als Membervariable einen Zeiger auf ein Objekt der Klasse B.

Objekte der Klassen A und B werden jeweils in main() mit new angelegt und wieder mit delete freigegeben. Ist das schlecht?

Grundsätzlich nicht. Aber angenommen im Destruktor von A wird b->free_resources() aufgerufen, wäre es schlecht wenn Du b vor a löscht. Denn dann wäre A von B abhängig. Und damit sowas nicht passiert, sollte man es anders lösen

WIE müsste ich das machen? Wie kann ich auf das Objekt überhaupt zugreifen? (es wurde ja kein Bezeichner eingeführt..)

Du hast in doSomething doch den Parameter, wo das Objekt übergeben wird!? DAS müsstest Du löschen - oder es anders machen

Das war deutlich. Scheiße sieht es wohl wirklich im Code aus und unsinnig ist es wahrscheinlich auch.

Kannst mir aber nochmal genauer erklären, warum es speichertechnisch nicht korrekt ist?

Es ist speichertechnisch nicht korrekt weil es keinen Speicher gibt. Es gibt nur einen Zeiger, und der zeigt auf nichts. Wenn Du "nichts"->irgendwas() aufrufst ist das schlicht und ergreifend nicht definiert.

Ok, ich übergebe einen undefinierten Zeiger, aber in der Methode wird ja dann mit new ein gültiges Objekt erzeugt und brav wieder freigegeben.

Das hast Du doch auskommentiert?!?

Das hast Du doch auskommentiert?!?

Dann hat du es falsch verstanden. Es sollte heißen, dass der auskommentierte Code für Fall4 (und nur für 4) als _nicht_ auskommentiert gelten soll.

War wohl etwas missverständlich.

Fall 4 ist totaler Müll

Das war deutlich. Scheiße sieht es wohl wirklich im Code aus und unsinnig ist es wahrscheinlich auch.

Kannst mir aber nochmal genauer erklären, warum es speichertechnisch nicht korrekt ist?

Naja, speichertechnisch ist es schon korrekt. Zumindest wird nichts Verbotenes gemacht. Das Problem hierbei ist, es ergibt keinen Sinn. Warum übergibst du einen Zeiger, mit dem überhaupt nichts gemacht wird? Der Zeiger selbst ist in der Funktion ja nicht verfügbar, da lediglich eine Kopie seines Wertes (Adresse) übergeben wird. Und diese ist undefiniert, also kann man damit nichts anfangen. Wenn du nichts übergeben würdest, hätte das den gleichen Effekt.

void doSomething()
{
    B* b = new B;
    b->whatEver();
    delete b;
}

int main()
{  
   a.doSomething();
}

Aber zu meinem ursprünglichen Problem: ich glaube/hoffe, ich konnte die Problemursache eingrenzen. Es liegt wohl irgendwie an einer Kopie eines Objekts, das seinerseits einen vector mit einem Klassentyp enthält.

Ein kleines Beispiel:

#include "B.h"
class A
{
    private:
        vector<B> myVector;
    public:
        A() {}
        void add_B(const B& b)
        {
            myVector.push_back(b)
        }
        const vector<B>& getVector() const
        {
            return myVector;
        }
};

class B
{
    private:
        int m_x;
    public:
        B(int x): m_x(x) {}
        int getX() const
        {
            return m_x;
        }
};

int main()
{
    A a1;
    B b;
    a1.add_B(b);
    A a2(a1); //COPY-Konstruktor!?
    cout << a2.getVector().getX(); //Hier kracht's
}

Und zwar bekomme ich bei diesem kleinen Programm den gleichen "Segementation Fault" -Fehler.

Muss ich in A einen Copy-Konstuktor für die Kopie des Vectors implementieren? Bisher dachte ich eigentlich, das würde die STL übernehmen.

P.S.: gutes Forum

Dein Problem ist, das mit

a2.getVector()

lediglich die std::vector Instanz selbst zurückgegeben wird. Und ein std::vector kennt nunmal keine Funktion getX. Du musst schon auf ein Element des Containers zugreifen, welches vom Typ B ist, damit du dann die Funktion getX aufrufen kannst.