K
Puh,
du bringst mich ja wieder ganz schön zum Grübeln - aber so soll es schließlich sein, sonst hätte ich mich hier nicht angemeldet!
SeppJ schrieb:
Was mir aber gerade auffällt ist, dass da ganz was abgefahrenes mit deinen statischen Membern abgeht. Du reinitialisierst die, wenn ein neues Objekt erzeugt wird? Das ist ganz schön merkwürdiges Verhalten. Und geändert werden sie danach auch nie. Wieso sind das dann keine Konstanten?
Also das Problem mit const ist ja, dass es nicht getrennt deklarieren und später initialisieren kann.
Das ganze lässt sich allerdings bei einer Klasse im Konstruktor als Ausnahme realisieren, wenn ich das richtig verstanden habe laut Wikieintrag.
Und dazu habe ich jetzt mal folgendes gebastelt:
class IonizationCS
{
public:
IonizationCS(double ionization_potential); // constructor
double get_cs_max(double T);
private:
const double A1, A2, B1, B2, a0, Ry, N;
double S, F1, F2, I;
};
// constructor
inline IonizationCS::IonizationCS(double ionization_potential):
A1(0.94), A2(1.13), B1(2.3), B2(22.0),//
a0(5.3e-9), // Bohrradius [a0] = cm
Ry(13.6), // Rydberg energy [Ry] = eV
N(2) // number of electrons per shell
{
I = ionization_potential;
S = 4 * M_PI * N * pow(a0,2)*pow(Ry/I,2);
}
SeppJ schrieb:
Und alle Member, egal ob static oder nicht, außer I und S, werden nur in einer Funktion benutzt. Warum sind I und S nicht die einzigen Member (die dann übrigens auch besser in einer Initialisierungsliste initialisiert würden) und der Rest funktionslokal in get_cs_max?
Das verstehe ich jetzt nicht. Ich habe also meine physikalischen Konstanten in eine Initialisierungliste gepackt, aber wieso I und S?
SeppJ schrieb:
Du sorgst dich also anscheinend um kleine Effizienzgewinne(inline), dafür machst du bei der grundlegenden Modellierung solche dicken Hauer (die dich am Ende dann auch Effizienz kosten werden). Da trifft mal wieder der berühmte Spruch zu, dass frühzeitigen Optimierung die Wurzel allen Übels ist.
Accepted - I am working on that!!
SeppJ schrieb:
statische Member müssen übrigens irgendwo leben (also irgendwo definiert werden), sonst knallt's beim Linken. Das dürftest du hier beobachtet haben.
Ja, das habe ich hier gemerkt. Aber wo müssen sie leben, dass sie global zur Verfügung stehen?
Soweit ich das verstanden habe reden wir ein wenig über den Unterschied zwischen const und static. Das Erste habe ich ein wenig als Selbstschutz des Programmierers verstanden. Also wenn er Variablen mit einem konstanten Wert haben möchte, dann deklariert er das ganze als const und kriegt einen Fehler ausgegeben, falls der Wert zur Laufzeit geändert werden würde (was ja nicht sein soll!)
Das Zweite ist ein wenig anders motiviert. Nämlich für den Fall, dass von dem Objekt der Klasse Kopien angelegt werden sollen, so wird das für static Members vermieden.
Bei mir würden Kopien angelegt werden, da mit jeder Kopie der Konstruktor aufgerufen wird, der wiederum ...
Auf der anderen Seite versuche ich auch ganz allgemein so viel wie möglich schon zu deklarieren, dass ich später nur noch initialisieren muss - also Werte zuweisen. Ich dachte dann spare ich die Hälfte an Zeitaufwand.
Allerdings beißt sich da gerade für const Werte die Katze in den Schwanz. Bzw. im Sinne der physik. Konstanten, die einfach allgemein zur Verfügung stehen sollen, reden wir ja eher über static.
Mir dreht sich langsam der Kopf ...
SeppJ schrieb:
edit2: Und der leere Destruktor ist auch typischer Cargo Cult.
Wieder was gelernt.
Gruß,
Klaus.
