R
camper schrieb:
Ramanujan schrieb:
Wenn ich diesen Code so sehe, fällt mir auf, dass ich an einer Stelle in meinem Programm auch sowas mache, es ist nur ein wenig komplexer und verworrener. Dann würde es sicher Sinn machen (übertragen auf diesen Beispiel), i als mutable zu deklarieren oder?
Ein besseres Design wäre ggf. vorzuziehen. Obwohl gegen mutable als solches keine theoretischen Einwände bestehen, hatte praktisch keine Bedeutung. Als kanonisches Beispiel wird ja häufig ein transparenter Cache gebracht. Eine Klasse, die so etwas benötigt und auch gleich intern selbst durchführt, kann allerdings kaum vermeiden, zur God-Klasse zu werden. Sobald die Funktionalität entsprechend auf verschiedene Objekte oder Klassen verteilt wird, verschwindet die Notwendigkeit für mutable ganz automatisch.
Ich hab mir meine Code nochmal anguckt: Es ist doch ok so, wie ich es gemacht hab: const bleibt const.
[quote="camper"]
Ramanujan schrieb:
Ramanujan schrieb:
camper schrieb:
Ramanujan schrieb:
mutable long const& m; //!< matrix row size
Gruselig. Memberreferenzen? Und dann auch noch mutable?
Bestimmt wird dann bei der Zuweisung auch noch wild mit Zeigern und Casts gewerkelt, um die Referenz umzubiegen. Es gibt eben Leute, die wollen sich das Bein wegschießen.
Das ist eine Klasse, die wohl zu Optimierungen da ist. In der ersten Zeile steht auch der Hinweise "// DO NOT USE". Da wird ganz bestimmt wild rumgewerkelt. Ich hoffe mal, dass der Autor alles richtig gemacht hat.
Da bin ich ja beinahe neugierig. Die Wahrscheinlichkeit, dass alles richtig gemacht wurde, ist allerdings sehr gering.
Die Bibliothek heißt CPPLapack. Siehe http://cpplapack.sourceforge.net/. Für Eigenwerte, SVD etc. werden die originalen Lapack-Funktionen genutzt.