| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
 Verfasst am: 16.04.2005, 09:27 Titel: |
 |
|
Zu 1.:
Benjamin Kaufmann hatte dazu man was feines verfasst was einen kurzen Überblick verschafft:
Q: Was ist const-correctness?
A: const-correctness hilft dabei bessere und sicherere Programme zu schreiben.
const-correctness basiert auf dem Schlüsselwort const, das ein Objekt um eine zusätzliche Typinformation erweitert. Diese Typinformation erlaubt es dem Compiler unerwartete Veränderungen an Objekten zu erkennen und diese als Fehler zu markieren. Ein Programm wird als const-korrekt bezeichnet, wenn es niemals ein konstantes Objekt verändert. Insofern sollte die Frage vielleicht eher lauten: "Wie erstelle ich const-korrekte Programme?"
Regel 1:
Jedes Objekt das nicht geändert werden soll oder nicht geändert werden muss, wird mit const qualifiziert.
Ausnahme:
Parameter die "by value" übergeben werden, sollten nicht const sein. Das const ist hier redundant, da ein solcher Parameter sowieso nicht von der Funktion verändert werden kann. Für den Compiler existiert hier nicht mal ein Unterschied:
| CPP: | void Func(int i) {}
void Func(const int i) {}
int main()
{
const int i;
int x;
Func(x);
Func(i);
}
|
Dieser Code wird nicht übersetzt, da void func(int) und void func(const int) die selbe Funktion beschreiben, hier also keine Überladung stattfindet.
Regel 2:
Funktionen/Methoden die "Return by value" verwenden, sollten immer ein konstantes Objekt liefern.
Ausnahme:
Diese Regel gilt nicht für die primitiven Typen (wie char, int, double usw.)
Regel 3:
Methoden die den logischen Zustand eines Objekts nicht ändern, sollten immer const sein.
Nun stellt sich natürlich die Frage nach dem Begriff logischer Zustand. Objekte besitzen zwei Zustände, die nicht notwendigerweise von einander abhängen. Jedes Objekt besteht letztlich nur aus einer Ansammlung von Bits. Den Zustand dieser Ansammlung bezeichnet man als physischen bzw. bitweise Zustand. Auf der anderen Seite existieren für jedes Objekt eine Reihe von öffentlichen Zugriffsmethoden. Diese bestimmen das Verhalten eines Objekts. Der logische Zustand beschreibt genau den Zustand, der über die öffentlichen Methode abgefragt werden kann. Das const einer Methode sollte sich immer auf den logischen Zustand beziehen. Ein physisches const kann auch gar nicht gewährleistet werden, da sich const nur auf den this-Zeiger bezieht, nicht aber auf das Objekt selbst:
| CPP: | class A
{
int x;
public:
A() {x = 0;}
void DoSomethingWithParam(A& Obj) const
{
Obj.x = 10;
}
int GetState() const {return x;}
};
int main()
{
A a;
int x = a.GetState();
// Durch das const wird NUR! verhindert, dass das Objekt über den
// this-Pointer verändert werden kann.
// Das const verhindert aber NICHT!, dass das Objekt über eine andere
// Referenz verändert werden kann.
a.DoSomethingWithParam(a);
int y = a.GetState();
if (x != y)
cout << "HILFE! Zustand wurde trotz const verändert!" << endl;
} |
Regel 4:
Methoden die den Zustand eines Objekts liefern, ohne ihn zu verändern, sollten const sein. Methoden die den logischen Zustand eines Objekts ändern, dürfen nicht const sein.
Die Methode der ersten Kategorie nennt man inspectors. Die der zweiten werden mutators genannt.
Manchmal benötigt eine Methode schreibenden Zugriff auf Instanzvariablen obwohl sie den logischen Zustand eines Objekts nicht ändert. Nun könnte man natürlich schulterzuckend Regel 3 ignorieren. Eine weitaus bessere Möglichkeit stellt die Verwendung des C++ Schlüsselworts mutable dar. Eine Instanzvariable die als mutable deklariert wurde, darf auch von const-Methoden verändert werden. Das folgende Beispiel zeigt eine solche Situation:
| CPP: | class KomplexData
{/*...*/};
class BspMutable
{
private:
// Data enthält viele Daten. Diese könnten z.B.
// aus einer DB stammen
KomplexData Data;
mutable long Cache;
mutable bool CacheValid;
long ProcessData() const
{
long result;
// Eine unglaublich komplexe Berechnung hier...
return result;
}
public:
// BuildStatistic cached das Ergebnis einer unglaublich
// komplizierten Berechnung. Falls der Cache ungültig
// geworden ist, muss er neu berechnet werden. In
// diesem Fall wird also ändernd auf Cache und CacheValid
// zugegriffen.
// Da Cache aber nicht zum logischen Zustand des Objekts gehört,
// sollte die Methode trotzdem const sein. Hier hilft mutable.
long BuildStatistic() const
{
if (!CacheValid)
{
CacheValid = true;
Cache = ProcessData();
}
return Cache;
};
KomplexData GetData() const {return Data;}
// Diese Methode verändert den logischen Zustand.
void ChangeData()
{
// Verändere Data
// Da die Daten verändert wurden ist der Cache
// nicht mehr gültig.
CacheValid = false;
};
};
|
const-correctness sollte gleich zu Beginn eines Projekts eine Rolle spielen. Nachträglich läßt sich const-correctness nämlich nur schwer erreichen. Ein neues const hier erfordert normalerweise fünf weitere consts da. Zwar kann ein nicht konstantes Objekt immer auch als konstantes Objekt behandelt werden, andersherum ist dies aber nicht möglich.
Fazit:
const-correctness macht das C++ Typsystem noch strenger. Und je strenger die Typprüfung, desto mehr Fehler können bereits zur Compilezeit entdeckt werden. Jeder Fehler der zur Compilzeit gefunden wird, ist einer weniger nach dem zur Laufzeit gesucht werden muss. Oder wie Herb Sutter sagt: be const-correct. const and mutable are your friends. Don't shoot yourself (or your fellow programmers) in the foot.
Literatur:
S. Meyers: "More effective c++ programming"
H. Sutter: "Exceptional C++"
M. Cline, G. Lomow, M. Girou: "C++ FAQs Sec. Edition"
zu 2.: was hast du genau geändert? Der scheint irgendwie die Implementierungen der Funktionen nicht mehr zu finden.
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
 |
HotAcid
Super JLI'ler
Alter: 43
Anmeldedatum: 04.08.2002
Beiträge: 372
Wohnort: Berlin
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 09:32 Titel: |
|
|
@Patrick: das ist doch mal ne nette "Übersicht" 
_________________
StGB §§ 328 Abs. 2 Pkt 3:
Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
|
| Nach oben |
|
|
Legolas87
JLI'ler
Alter: 37
Anmeldedatum: 22.10.2003
Beiträge: 131
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 11:33 Titel: |
|
|
vielen dank schon mal für 1 patrick. ich denke regel 3 verdeutlicht das, was fheinemann gemacht hat.
zu2: ich habe ganz einfach nur den namen des namespace geändert, konsequent an allen stellen. weitere änderungen wollte ich erst nach einem funktionstest machen. |
|
| Nach oben |
|
|
xardias
JLI Master
Alter: 39
Anmeldedatum: 28.12.2003
Beiträge: 804
Wohnort: Palo Alto, CA
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 12:17 Titel: |
|
|
| ab ins faq damit würde ich mal sagen |
|
| Nach oben |
|
|
Jonathan_Klein
Living Legend
Alter: 37
Anmeldedatum: 17.02.2003
Beiträge: 3433
Wohnort: Siegerland
Medaillen: Keine
|
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
|
| Nach oben |
|
|
Jonathan_Klein
Living Legend
Alter: 37
Anmeldedatum: 17.02.2003
Beiträge: 3433
Wohnort: Siegerland
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 14:31 Titel: |
|
|
naja, ok, aber du hast das gepsotets, und net ich *g*
_________________
https://jonathank.de/games/ |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 14:34 Titel: |
|
|
Ich habe als aller erstes einen Verweis auf die Person gepostet die die Rechte daran hat! Ich habe keinerlei Rechte daran sondern nur das Recht es mit eindeutigem Verweis auf den Urheber zu posten was ich getan habe!
Also: FAQ Eintrag raus! Wenn ihr wollt kann ich sowas ähnliches schreiben damit ihr kein Urheberrecht verletzt.
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
HotAcid
Super JLI'ler
Alter: 43
Anmeldedatum: 04.08.2002
Beiträge: 372
Wohnort: Berlin
Medaillen: Keine
|
| Verfasst am: 16.04.2005, 16:32 Titel: |
|
|
oh sorry mal wieder nicht genau genug gelesen 
_________________
StGB §§ 328 Abs. 2 Pkt 3:
Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. |
|
| Nach oben |
|
|
Legolas87
JLI'ler
Alter: 37
Anmeldedatum: 22.10.2003
Beiträge: 131
Medaillen: Keine
|
| Verfasst am: 19.04.2005, 19:26 Titel: |
|
|
| kommt hier noch ne antwort? |
|
| Nach oben |
|
|
DirectXer
Dark JLI'ler
Anmeldedatum: 05.02.2005
Beiträge: 1201
Wohnort: Köln
Medaillen: Keine
|
| Verfasst am: 19.04.2005, 19:31 Titel: |
|
|
| hmm, wenn du den Namespace wieder in die alte Konstruktion änderst, gehts dann? |
|
| Nach oben |
|
|
Legolas87
JLI'ler
Alter: 37
Anmeldedatum: 22.10.2003
Beiträge: 131
Medaillen: Keine
|
| Verfasst am: 20.04.2005, 13:10 Titel: |
|
|
wenn ich alles so lasse, wie es war kommt folgende meldung
Linker-Vorgang läuft...
engine.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: __thiscall FDX::Exception::~Exception(void)" (??1Exception@FDX@@QAE@XZ)
engine.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: __thiscall FDX::Exception::Exception(unsigned int)" (??0Exception@FDX@@QAE@I@Z)
main.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall FDX::Exception::GetErrorString(void)" (?GetErrorString@Exception@FDX@@QAE?AV?$bas
ic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
Debug/engine.exe : fatal error LNK1120: 3 unaufgeloeste externe Verweise
Fehler beim Ausführen von link.exe. |
|
| Nach oben |
|
|
DirectXer
Dark JLI'ler
Anmeldedatum: 05.02.2005
Beiträge: 1201
Wohnort: Köln
Medaillen: Keine
|
| Verfasst am: 20.04.2005, 14:03 Titel: |
|
|
also, 2 Fragen: Hat es bei dir jemals schon mal geklappt?, oder geht es erst nicht, wenn du etwas veränderst?
Wenn ja, geht es denn wieder, wenn du alles zurückstellst? |
|
| Nach oben |
|
|
Legolas87
JLI'ler
Alter: 37
Anmeldedatum: 22.10.2003
Beiträge: 131
Medaillen: Keine
|
| Verfasst am: 20.04.2005, 19:55 Titel: |
|
|
| ich habe einen arbeitsbereich erstellt und die dateien unverändert kompiliert; es hat also noch nie geklappt. |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
