Funktion zur Überprüfung der Setzung
-
Jester schrieb:
Gute Idee, aber wie fragt man ab, ob die bool-Variablen korrekt gesetzt worden sind?
Man erzwingt einfach, daß sie korrekzt gesetzt wurden. Dafür ist der Konstruktor da.
Aber warum erzwingt man nicht einfach auch, daß die Hauptvariablen korrekt gesetzt wurden? Wäre viel besser, als irgendwo zur Laufzeit Exceptions zu werfen.
-
Danke volkard :). Du meinst also zu jeder Variablen eine boolsche Variable begleitend?
void setzeSitzplaetze(int sitzplaetze){ this->anzahlSitzplautze = sitzplaetze; anzahlSitzplautzeGesetzt = true; } bool istSitzplaetzeGesetzt(){ return anzahlSitzplautzeGesetzt; }Wäre das so ok für die Sitzplaetze?
-
class Auto { private: double masse; int anzahlSitzplaetze; public: Auto(double masse,int anzahlSitzplaetze) :masse(masse) ,anzahlSitzplaetze(anzahlSitzplautze){ //fertig. Das Setzen kann nicht vergessen werden. //jemand darf ein Auto gefälligst erst bauen, wenn er dessen //Daten weiß. } double getMasse(){ return masse; } double getAnzahlSitzplaetze(){ return anzahlSitzplaetze; } };
-
Das heisst also die daten werdem im Konstruktor übergeben? Nur wenn die Übergabe erfolgt kann ein solches Objekt erst generiert werden?
-
nadine.wolken schrieb:
Das heisst also die daten werdem im Konstruktor übergeben? Nur wenn die Übergabe erfolgt kann ein solches Objekt erst generiert werden?
Ja, das wäre die saubere Lösung.
Objekte versprechen, daß sie korrekt initialisiert wurden.Dann gibt es auch keine Frage, ob die Daten alle da sind. Sie sind da.
Man darf alle Methoden aufrufen, weil das Objekt vollständig lebt.Entsprechend fragt man auch nicht, ob ein Klassenobjekt lebt. Wenn es existiert, dann lebt es. Dann wurde es korrekt initialisiert.
Im Zusammenhang mit Zeigern kann man fragen, ob der Zeiger auf ein existierenden Objekt zeigt oder auf NULL, wo kein Objekt wohnen darf.
-
Vielen Dank volkard :). Wenn du das gerade ansprichst mit NULL und Objekten, wie sieht das mit structs eigentlich aus wenn nein Objekt von einem struct erzeugt wurde kann man ja nicht die Abfrage != NULL machen. Wie sieht es dort aus?
-
volkard schrieb:
Jester schrieb:
Gute Idee, aber wie fragt man ab, ob die bool-Variablen korrekt gesetzt worden sind?
Man erzwingt einfach, daß sie korrekzt gesetzt wurden. Dafür ist der Konstruktor da.
oder eben doch ein "bool masseGesetztGesetzt"?

-
Ähm,
structist praktisch dasselbe wieclass! (Bis auf die default-access-specifier)
-
@Sone: aber man kann die Abfrage != NULL mit structs nicht machen.
-
nadine.wolken schrieb:
@Sone: aber man kann die Abfrage != NULL mit structs nicht machen.
Ähm, Nadine,

Diese Abfrage sollst du eigentlich nur bei Zeigern anwenden*.
Und technisch gesehen kannst du das auch nur bei skalaren Typen (int,float,char, Zeiger, .....), solangeNULLeben einfach 0 ist.Das geht also bei Klassen, egal mit welchem class-key deklariert, nicht.
Wie bereits alle anderen gesagt haben, muss man das ganz anders angehen.
~*In C++11 ist es auch nicht NULL sondern nullptr.~
-
P.S.: Das ist alles unter dem Konzept RAII bekannt.
-
Dieser Beitrag richtet sich an nadine.wolken, auch wenn ich Sone zitiere:
Sone schrieb:
Diese Abfrage sollst du eigentlich nur bei Zeigern anwenden*.
Und technisch gesehen kannst du das auch nur bei skalaren Typen (int,float,char, Zeiger, .....), solangeNULLeben einfach 0 ist.Eigentlich kannst du das alles auch nicht. Zumindest nicht, wie es hier gemeint ist. Bei skalaren Typen hast du wieder zwei Probleme:
1. Es muss sowieso schon eine Initialisierung erfolgt sein, sonst wären sie nicht 0/NULL. Wieso nicht gleich richtig initialisieren?
2. Was ist, wenn 0/NULL der gewünschte Wert ist?
Bei Pointern kommt noch hinzu, dass 0 und NULL andere Bedeutung haben, als du denkst. Wenn du viele (oder überhaupt) Prüfungen auf NULL in deinem Code hast, dann ist dies fast immer ein Zeichen, dass du nach einem schlechten Buch gelernt hast, dessen Autor selber keine Ahnung hatte. Sichere Alarmzeichen sind unter anderem:Foo *foo = new Bar; if (foo == NULL) ...if (foo != NULL) delete foo;
-
SeppJ schrieb:
Sichere Alarmzeichen sind unter anderem:
if (foo != NULL) { delete foo; foo = NULL; }
-
nadine.wolken schrieb:
Vielen Dank volkard :). Wenn du das gerade ansprichst mit NULL und Objekten, wie sieht das mit structs eigentlich aus wenn nein Objekt von einem struct erzeugt wurde kann man ja nicht die Abfrage != NULL machen. Wie sieht es dort aus?
struct und class haben hier keinen Unterschied! Es ist nicht so, daß man structs immer direkt hinschreiben müßte!
//struct Rectangle Rectangle rect(10,10,300,620); g->FilleRectangle(redBrush,&rect));Man kann structs auch sehr wohl mit new anlegen und über Zeiger anfassen.
//struct Rectangle Rectangle* rect=new Rectangle(10,10,300,620); g->FilleRectangle(redBrush,rect)); delete rect;Aber das wäre hier doof.
Und Klassenobjekte muss man nicht immer mit new anlegen.
Statt//class Solidbrush SolidBrush redBrush=new SolidBrush(Color::Red); g->FilleRectangle(redBrush,&rect)); delete redBrush;macht man viel lieber
//class Solidbrush SolidBrush redBrush(Color::Red); g->FilleRectangle(&redBrush,&rect));Nehmen wir mal an, es gäbe für SolidBrush nur einen einzigen Konstruktor. Und der will eine Farbe als Parameter.
Dann ist es unmöglich ein SolidBrush-Objekt zu erzeugen, das keine Farbe hat. Man kann das Setzen der Farbe nicht vergessen.SolidBrush brush1;//Compilerfehler! Kann keinen Brush auf dem Stack erzeugen, //wenn ich dem Konstruktor keine Farbe anbiete. SolidBrush *brush1=new Solidbrush;//Compilerfehler! Kann keinen Brush auf dem Stack erzeugen, //wenn ich dem Konstruktor keine Farbe anbiete.Insofern sind sie hier gleich. Und für structs gilt das auch. Wenn sie Konstruktoren haben, wir einer davon verwendet und die Klasse/Struct bleibt nicht uninitialisiert.
Was GANZ anderes ist
SolidBrush *brush1;Es wurde kein SolidBrush angelegt. Nur ein Zeiger auf SolidBrush und der Zeiger wurde nicht inistialisiert, was böse ist. Schreibst ja auch nicht irgendwo im Code ein unmotiviertes
int i;und erst ein paar Zeilen später i=1; oder so.
-
sag mal, bist du rein zufällig eine enge Bekannte von tanja.hopfer?
Der Fragestil lässt sehr darauf schließen, ebenso das Fehlen von Quellcode...
edit: und natürlich ganz offensichtlich derselbe Nickname-Stil.
-
Das hab ich auch schon gedacht! Die Probleme klingen auch ähnlich.