Ich habe bereits die Suchfunktion benutzt, aber keinen passenden Beitrag gefunden.

Ich versuche gerade eine BigInt Klasse zu schreiben, die dynamisch Speicher reserviert.
Die Ergebnisse stimmen, aber nach längerem Rechnen geht der Speicher aus.
Ich habe mich an einen C++-Kurs der Uni München gehalten.

Hier die wichtigsten Methoden auf "new" und "delete" reduziert:

Private Attribute:

int length;
char *digits;

BigInt::BigInt(const char *str){

	this->length=strlen(str);
	digits = new char[length+1];	

        //String kopieren
        //Ohne Param einfach length=0;
}

BigInt BigInt::operator + (const BigInt &n)const{
	BigInt b;

	b.length = MAX(this->length,n.length);
	b.digits = new char[b.length+1];

	//Rechne und schreibe in b

	return b;
}

BigInt BigInt::operator * (const BigInt &n)const{
	BigInt b,tmp;
	tmp.digits=new char[this->length+n.length];	

	//Rechne und schreibe in b

	tmp.~BigInt();
	return b;
}

BigInt &BigInt::operator = (const BigInt &n){
	digits = new char[n.length];
	length=n.length;

        //Kopier n nach this

	return *this;
}

BigInt::~BigInt(){
	delete[] digits;
	digits=NULL;
}

Ursprünglich wollte ich damit 1¹ + 2² + ... + 1000^1000 berechnen, bekomme später als Ausgabe killed.

Selbst wenn ich die Ergebnisse bei berechnungen direkt lösche wirft die Konsole killed

const BigInt power(int i){
	//Pack i in str

	BigInt tmp=str, b=str;

	for (j=1; j<i; j++)
		b=b*tmp;

	tmp.~BigInt();	
	return b;
}

int main(){
	for (int i=1; i<=1000; i++)
		power(i).~BigInt();	

	return 0;
}

Wo geht der Speicher verloren?

Hier die wichtigsten Methoden auf "new" und "delete" reduziert:

Ich sehr zumindest vieles, was ich in zweifel ziehe.

1. Ich würde nicht die Allokation von Außen erlauben, und mir missfällt aus eben jenen Gründen auch die Implementierung von deinem operator +. Meines Erachtens sollte eine Instanz für seine Daten verantwortlich sein (Sprich: Konstruktor, und nicht nachträgliches einzelnes anpassen).

2. Man ruft eigentlich niemals den Destruktor direkt auf (z.B. operator *, main...), dies geschieht ohnehin wenn eine Stackvariable den Scope verlässt, oder du ein delete auf ein Heapobjekt anwendest.

3. Dein Zuweisungsoperator hat ein Speicherleck, da du den vorher allokierten Speicher von digits nicht freigibst.

4. Das NULL-Setzen eines Zeigers im Destruktor ist nur notwendig, wenn darauf noch zugegriffen wird. Und nun... der Destruktor sollte eigentlich das Ende eines Objektes sein (Es sei den man verwendet den Destruktor wie bei dir falsch).

5. Ein Kopierkonstruktor fehlt (obwohl hier nötig).

Wo geht der Speicher verloren?

Praktisch überall. Zu jedem new muss ein delete aufgerufen werden. Das einzige new-delete-Paar das ich sehe ist das new im Konstruktor und das delete im Destruktor. In praktisch jeder Operation reservierst du neuen Speicher und gibst ihn nicht frei.

Oh, und du rufst einen Destruktor manuell auf. Das ist auch eine sehr zweifelhafte Aktion.

ich sehe bei gar keinen Kopierkonstruktor. Hast Du keinen? Du rufst auch manuell einen Destruktor auf ( tmp.~BigInt(); ). Das ist in diesem Fall falsch. Man ruft den Destruktor so gut wie nie manuell auf. Das passiert automatisch, wenn das Objekt ein "automatisches" ist (nicht separat im Freispeicher angelegt) oder Datenelement eines anderen Objekts ist, welches zerstört wird.

Andere Anregungen:
- Du hättest Dir viel an Verwaltungsaufwand bzgl new/delete sparen können, indem Du einfach einen std::string als Datenelement in BigInt benutzt.
- Es sieht so aus, als ob Du die Dezimaldarstellung zum Speicher benutzt. Alternativ könnte man ein p-adisches System mit p=256, p=65536 oder p=2^32 benutzen. Statt std::string wäre dann zB std::vector<uint32_t> angebracht.

Du musst das Rad auch nicht neu erfinden. Wenn Du weniger an der eigenen Implmentierung von BigInt interessiert bist und hauptächlich damit nur rechnen willst, kannst Du Dich auch umgucken.

Ich wollte lernen...

*Speicher richtig zu verwalten
*Operatoren richtig überladen
*Mit Objekten in C++ arbeiten

Ich komme aus der Java-Sparte, denn an meiner Uni wird fast nur das gelehrt. Ein bischen C habe ich in Betriebssysteme gelernt, aber das ist eben nicht OOP.

2. Man ruft eigentlich niemals den Destruktor direkt auf (z.B. operator *, main...), dies geschieht ohnehin wenn eine Stackvariable den Scope verlässt, oder du ein delete auf ein Heapobjekt anwendest.

Wie ruft man denn sonst einen Destruktor auf? Wann soll das Objekt denn wissen, dass es stirbt? Reicht es demnach einfach nur, den Destruktor implementiert zu haben oder wie?

3. Dein Zuweisungsoperator hat ein Speicherleck, da du den vorher allokierten Speicher von digits nicht freigibst.

Das hab ich mir auch schon mal gedacht und davor "delete[] digits;" aufgerufen, dadurch ist das Programm immer abgestürzt.

5. Ein Kopierkonstruktor fehlt (obwohl hier nötig).

Wo brauche ich den denn?

- Du hättest Dir viel an Verwaltungsaufwand bzgl new/delete sparen können, indem Du einfach einen std::string als Datenelement in BigInt benutzt.

Ja oder ein dynamisches Array oder ich reserviere gleich ein char-Array mit 10.000 Stellen für jedes BigInt

Ich bin voll am verzweifeln. Ich möchte gerne wissen wie man richtig Ojekte übergibt, Speicher reserviert und freigibt, ohne das der Garbage Collector einem alles in den A**** schiebt bzw eher rausholt

Ich komme aus der Java-Sparte, denn an meiner Uni wird fast nur das gelehrt. Ein bischen C habe ich in Betriebssysteme gelernt, aber das ist eben nicht OOP.

C++ auch nicht (zumindest nicht ausschließlich), C++ ist eine Multiparadigmensprache, aber das nur am Rande.

anjohn schrieb:

Wie ruft man denn sonst einen Destruktor auf? Wann soll das Objekt denn wissen, dass es stirbt? Reicht es demnach einfach nur, den Destruktor implementiert zu haben oder wie?

Ja, das reicht. Der Compiler weiß wann ein Objekt stirbt, da es in C++ keinen GC wie in Java gibt, und Objekte direkt gelöscht werden.

{
    A a; // <-- A()
}        // <-- ~A()

{
    A * a;
    a = new A(); // <-- A()
    delete a;    // <-- ~A()
}

anjohn schrieb:

3. Dein Zuweisungsoperator hat ein Speicherleck, da du den vorher allokierten Speicher von digits nicht freigibst.

Das hab ich mir auch schon mal gedacht und davor "delete[] digits;" aufgerufen, dadurch ist das Programm immer abgestürzt.

Das liegt aber nicht am "delete[] digits;". Du hattest sicherlich noch andere Fehler (z.B. das durch den Fehlenden Kopierkonstruktor Speicher zwischen 2 Objekten "geteilt" wurde, aber in einem freigegen wurde, und du nun versuchst das Objekt zum zweiten Mal zu löschen).

Flache und Tiefe Kopie wären hier ein paar Stichworte...

anjohn schrieb:

5. Ein Kopierkonstruktor fehlt (obwohl hier nötig).

Wo brauche ich den denn?

Jedesmal wenn du ein Objekt kopierst. C++ arbeitet im Gegensatz zu Java mit Objekten und nicht Referenzen.

void foo1(A a)
{
}

void foo2(A const & a)
{
}

{
  A a;     // <-- A()
  A b = a; // <-- A(A const &) => Kopierkonstruktor
  foo1(b); // <-- A(A const &) => Kopierkonstruktor, da Wertübergabe
  foo2(b); // Keine Kopie, da Referenzübergabe
}

Ich wollte lernen...
*Speicher richtig zu verwalten
*Operatoren richtig überladen
*Mit Objekten in C++ arbeiten

Du solltest wissen, dass der Compiler automatisch Default-Kopierkonstruktor, -Zuweisungsoperator und -Destruktor erzeugt, falls möglich. Diese tun in einigen Fällen nicht das, was sie sollen -- wie zB in Deinem Fall.

Und Speicher kann man genauso "richtig" verwalten, in dem man die Standard-Container benutzt. ZB so:

class bigint
{
  std::vector<uint32_t> digits
public:
  bigint(long = 0);
  ...
};

Hier musst Du Kopierkonstruktor, Zuweisungsoperator und Destruktor nicht selbst schreiben. Die, die vom Compiler automatisch generiert werden, machen genau das richtige. Das sollte auch die Regel sein. Wenn Du es für nötig hältst, diese Funktionen für viele Deiner Klassen manuell zu schreiben, dann ist das ein Indiz dafür, dass Du die Sprache nicht optimal ausnutzt.

Wenn Du einen Zeiger als Datenelement hast, wobei dieser Zeiger auf etwas zeigt, was dem Objekt "gehört" (in dem Sinne, dass das Objekt zB für die Löschung verantwortlich ist), dann musst Du dem Compiler sagen, wie ein Objekt dieses Typs "richtig" kopiert, zugewiesen und zerstört wird, weil das Kopieren, Zuweisen und Zerstören eines Zeigers nicht den gewünschten Effekt hat.

Der Default-Kopierkonstruktor versucht einfach alle Datenelemente zu kopieren -- was auch immer "Kopieren" bedeutet. Bei std::vector bedeutet "Kopieren", dass der neu erstellte Vektor seine eigenen Elemente als Kopie besitzt:

vector<int> foo;
foo.push_back(23);
vector<int> bar = foo;           // Kopierkonstruktor von vector<int>
bar.at(0) = 42;
std::cout << foo.at(0) << '\n';  // gibt immernoch 23 aus

(und das ist auch gut so)

anjohn schrieb:

Ich komme aus der Java-Sparte, denn an meiner Uni wird fast nur das gelehrt. Ein bischen C habe ich in Betriebssysteme gelernt, aber das ist eben nicht OOP.

Ging mir genauso. Habe mir C++ auch erst am Ende des Studiums unter Verwendung von schlauen Büchern selbst beigebracht. Fazit: Schlaue Bücher lohnen sich.

anjohn schrieb:

Wie ruft man denn sonst einen Destruktor auf? Wann soll das Objekt denn wissen, dass es stirbt? Reicht es demnach einfach nur, den Destruktor implementiert zu haben oder wie?

So ähnlich. Üblicherweise findet das Allozieren und Initialisieren direkt hintereinander statt. Beim Zerstören und Freigeben sieht das genauso aus. Du musst ja auch eine "automatische" (auf dem Stack liegende) int-Variable nicht extra zerstören. Das passiert von ganz allein. C++ erlaubt es Dir, eigene Typen zu erstellen, bei denen Du festlegen kannst, was passieren soll, wenn sie kopiert, zugewiesen oder zerstört werden. Das mit dem Zerstören passiert entweder automatisch oder per delete , falls das Objekt im Freispeicher erzeugt wurde. Es gibt Ausnahmen, aber die interessieren erstmal nicht.

anjohn schrieb:

5. Ein Kopierkonstruktor fehlt (obwohl hier nötig).

Wo brauche ich den denn?

Wenn Du ihn nicht selbst schreibst, wird einer automatisch generiert. Und dieser automatisch generierte, macht in diesem Fall etwas falsches. Eine Klasse, die sich wie int verhalten soll, muss natürlich kopierbar und zuweisbar sein.

Wenn Du es für nötig hältst, diese Funktionen für viele Deiner Klassen manuell zu schreiben, dann ist das ein Indiz dafür, dass Du die Sprache nicht optimal ausnutzt.

Klingt sehr weise

Praktisch überall. Zu jedem new muss ein delete aufgerufen werden. Das einzige new-delete-Paar das ich sehe ist das new im Konstruktor und das delete im Destruktor. In praktisch jeder Operation reservierst du neuen Speicher und gibst ihn nicht frei.

Also ich habe jetzt noch einen Kopier-Konstruktur aber das ist natürlich nicht die Lösung des Speicherproblems.
Wenn ich meine Objekte nicht selber löschen soll, wieso fehlen dann new-delete-Paare?
In meinen Rechenoperationen für Multiplikation und Addition erzeuge ich jeweils ein neues BigInt-Objekt und gebe es als Rückgabewert der Funktion aus.

Wenn jetzt folgendes passiert: bigint3 = (bigint1+bigint2)
Das Objekt das bei der Addition erzeugt wird, stirbt, nachdem es vom Gleichheitsoperator nach bigint3 kopiert wurde oder? Ich hatte immer das Gefühl dass das erzeugte Objekt nachher im Speicher rumirrt...

Und habe ich es dann richtig verstanden? Wenn ich z.B. mit int *peter = new int[100] Speicher allokiere, und später wieder peter = new int[200] sage, dann habe ich zwar für 200 Integer Speicher reserviert, aber die alten 100 Felder sind verloren weil ich sie hätte freigeben müssen?

http://www.etp.physik.uni-muenchen.de/kurs/Computing/ckurs/node36.html
Was sagt ihr denn zu dieser Übung? Macht man das dann überhaupt so?

Danke für die ganzen Antworten, sehr kompetentes Forum muss ich sagen