Eben nicht! Man hätte viel mehr Rumgebastel und die Datenstruktur wäre komplizierter. So kann man z.B. memcpy verwenden und muß nicht überall ein Array aus Pointern vewalten… arghl!
Wie schon erwähnt, wäre es auch nicht performant.
EDIT: std::vector: Da hätte man das gleiche Problem und zusätzlich noch die Verwaltungsdaten für die vector Objekte → bad idea
Prinzipiell ist es ja in dem Fall ja etwas in der Art. Das Problem ist aber dennoch, dass Templates nicht so 100%ig in die standard Makefilekonventionen passen.
wo wir schon dabei sind:
Der Return-Typ von Matrix::operator= ([m]“Matrix operator=(const Matrix &other);”[/m]) ist ungewoehnlich,
normalerweise wuerde man “Matrix &” zurueckgeben (sag ich…).
na na na, „man“ verwendet doch std::copy :-p
Das ist Ansichtssache…
Es hat so auch seine Vorteile (es wird naemlich der Copy Konstruktor aufgerufen)
Hehe, stimmt, SP versaut enen halt total… 
Mal gucken, ob in den Übungen noch ein iterator auftaucht.
Den Cpyctor aufzurufen scheint mir aber kein Vorteil zu sein^^
Ohne Optimierung wuerde der Operator (nach der eigentlichen Zuweisung an this) noch eine Matrix-Instanz als Rueckgabewert erzeugen,
die evtl gar nicht gebraucht wird.
Was ist in der Angabe mit “Zeilen zuerst” gemeint?
Eine Matrix hat n Spalten und m Zeilen. D.h. width = n und height = m ?
0 1 2 3
0 1 2 3
0 1 2 3
0 1 2 3 → Zeilen zuerst 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
→ Spalten zuerst 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3
(Speicherlayout)
Thx. Was ist mit Fehlerbehandlung gemeint? Ganz klassisch wie in C: Fehlermeldung ausgeben und abbrechen oder irgendwas mit Exceptions (gibts sowas in C++?) ?
Laut meinem Uebungsleiter reichen asserts… Was in meinen Augen zwar nicht direkt eine Fehler"behandlung" darstellt aber was solls 
Braucht man dafür in C++ auch extra Compilerflags oder geht das automatisch?
Fehler werden nicht automatisch behandelt… Nein, für was ?
Kann mich erinnern, dass man in JAVA ein extra Compilerflag gebraucht hat, um asserts zu aktivieren.
assert() ist immer an, ausser das Präprozessormakro NDEBUG ist definiert:
gcc -DNDEBUG ...oder
#define NDEBUG // so sollte man's aber nicht machensiehe auch [m]/usr/include/assert.h[/m]
zur Fehlerbehandlung:
-Also assert() reicht aus und ist schnell hingeschrieben
-etwa in der Art if (Fehler) { std::cerr << “fehler”; exit(0); } ist auch ok
-Exception werfen ist eigentlich konzeptionell das Beste, aber es wurde nirgends besprochen
Stimmt doch gar nicht. Du brauchst ein flag für das runtime environment.
Hab ez nich alle Beiträge gelesen, aber falls sich jemand wundert warum er mit der main aus diesem Thread und valgrind Speicherlecks hat:
Die main erzeugt 15 Objekte mit new, deleted sie aber nicht mehr.
Also wer 15 not-freed blocks hat, hat kein Problem, alles drüber is nix gut
Wozu das denn? Das geht doch auch alles auf dem Stack. Am besten RAII lernen:
C++ != C, nix malloc, nix einfach so Speicher überall rumfliegen lassen.
$ valgrind ./A1
[...]
==9495== HEAP SUMMARY:
==9495== in use at exit: 0 bytes in 0 blocks
==9495== total heap usage: 11 allocs, 11 frees, 188 bytes allocated
==9495==
==9495== All heap blocks were freed -- no leaks are possible
==9495==
==9495== For counts of detected and suppressed errors, rerun with: -v
==9495== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)EDIT:
Sowas hier ist Mist (aus main.cpp von oben):
c32.setEntry(0,0, *(new Complex(1,1)));Einfach
c32.setEntry(0,0, Complex(1,1));