OOP mal wieder

[Badestrand]

Sqwan schrieb:

Google sacht mir da so nen zeuch mit 3 diminensionalem raum im koordinatensystem

Das ist ein Vektor im mathematischen Sinne, hier ist es einfach ein Array aus der Std-Bibliothek

[Sqwan]

Also ich habe mal was versucht...

sieht so aus...

#include <iostream>

using namespace std;

class Rechnen
{

private:
	float zahl1;
	float zahl2;
	char operators;
	float ergebnis;

public:

	//So wie ich es verstanden habe der Konstruktor
	void Calculator()
	{
		zahl1 = 0;
		zahl2 = 0;
		operators = 'z';
		ergebnis = 0;
	}

	//Methode
	void newZahl1(float zahl)
	{
		zahl1 = zahl;
	}

	//Methode
	void newZahl2(float zahl)
	{
		zahl2 = zahl;
	}

	//Methode
	void setOperator(char zeichen)
	{
		operators = zeichen;
	}

	//Methode
	void calculate()
	{
		switch(operators)
		{
			case '+': ergebnis = zahl1 + zahl2; break;
			case '-': ergebnis = zahl1 - zahl2; break;
			case '*': ergebnis = zahl1 * zahl2; break;
			case '/': ergebnis = zahl1 / zahl2; break;
			default:  cout<<"Falsche Eingabe!"<<endl; break;
		}
	}

	//Methode
	void ShowResult()
	{
		cout<<zahl1<<" "<<operators<<" "<<zahl2 <<" = "<<ergebnis;
	}
};

void main()
{
   Rechnen rechenmaschine;
   rechenmaschine.Calculator();
   rechenmaschine.newZahl1(10);
   rechenmaschine.newZahl2(20);
   rechenmaschine.setOperator('+');
   rechenmaschine.calculate();
   rechenmaschine.ShowResult();
}

kommt mir sehr sinnlos rüber und irgendwie falsch.
Denn vorher hatte ich weniger quellcode.
Und leichter sah es vorher auch aus.
Nur geordneter is es glaube ich ein wenig

[thordk]

//So wie ich es verstanden habe der Konstruktor
    void Calculator()

ein konstruktor heisst stets genau wie die klasse und hat keinen rückgabetyp. void IST ein rückgabetyp, der keinen wert liefert (umgangssprachlich, void zeiger können sehr wohl wieder auf einen "wert" zeigen).

in deinem beispiel müsste der konstruktor also wie folgt lauten

class Rechnen
{
 ...
 Rechnen() // konstruktor
 {
 ...
 }
};

was OO ausmacht ist, wie hier bereits erwähnt, grundsätzlich erstmal ein anderes verständnis des problems. man versucht in dem problem auszumachen, wo sich objekte befinden. ein gutes beispiel ist vielleicht ein apfelbaum.

ein apfelbaum hat äste, blätter und früchte.

zu den ästen gehört auch der stamm, die wurzeln und das, was man typischerweise als äste bezeichnet. die blätter und früchte hängen immer an den ästen.

je nach gewünschter granularität kann man hier nun aufteilen. vielleicht benötigt man die unterteilung in äste, stamm und zweige gar nicht und nennt das grundkonzept einfach nur "baum". dieser baum hat dinge, die an ihm dranhängen. nennen wir es "zeugs". "baum" ist also ein container, der "zeugs" beinhaltet.

class Baum
{
 vector<Zeug*> zeugs;

 public:
  addZeugs(Zeug* zeug){ zeugs.push_back(zeug); }
};

dieses zeugs kann nun entweder ein blatt oder ein apfel sein, womit man schon beim thema vererbung wäre. blätter und äpfel sind beide vom typ "zeugs", aber da man beide anders behandeln will, schafft man sich zwei verschiedene klassen dafür.

class Zeug
{
 string name;
};

class Apfel : public Zeugs
{
 Apfel(){ name = "Apfel"; }
};

class Blatt : public Zeugs
{
 Blatt(){ name = "Blatt"; }
};

[delete]

Ah ja soviele Tutorials hast du durchgearbeitet und noch nicht mal nen Konstruktor kriegst du hin. Ich glaube du hast dir nicht viel Mühe gegeben.

[Sqwan]

gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...

Vllt bin ich auch einfach zu blöde mir ordnetliche OOP tuts zu suchen...

und wie ich das hier sehe habe ich es immer ziemlich falsch verstanden...
das letzt was ich gelesen(eher überflogen) habe, stand drinne das eine prog häufig mehrere aufgaben hat...

Jede aufgabe bekommt ein Objekt..
Und im objekt teilt man dann die probleme in die methoden...

So wie ich es jetzt verstanden habe, teilt man die probleme einer aufgabe in objekte auf... und die probleme teilt man dann in die methoden...
Oder sehe ich das falsch...

EDIT:
habe grade eine tut gefunden da steht drinne das ein konstruktor in Java den selben namen haben muss...

[Gast]

Sqwan schrieb:

gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...

Zitat aus C++, die Programmiersprache, Seite 240 (KOnstruktoren): "Ein Konstruktor ist dadurch gekennzeichnet, daß er denselben Namen hat wie die zugehörige Klasse".

Manchmal hilft es wirklich die Standartwerke zu besitzen... Und sie auch zu lesen

[Badestrand]

Wi wir schonmal dabei sind: Ein Destruktor hat auch denselben Namen wie die Klasse, nur mit ~ davor. Und du brauchst weder Konstruktor noch Destruktor extra aufzurufen

class Cl
{
    public:
        Cl()
        {
            cout << "Konstruktor" << endl;
        }

        ~Cl()
        {
            cout << "Destruktor" << endl;
        }
};

void IrgendNeFunktion()
{
    Cl BlaVariable; //--> Hier wird der Konstruktor aufgerufen
    ...
    //--> Und hier der Destruktor, genau vor der Klammer-Zu
}

void Func2()
{
    Cl* pVar;
    ...
    Cl = new Cl; // Konstruktor
    ...
    delete Cl;  // Destruktor
    ...
}

[und tschüss!]

http://www.cpp-tutor.de

Wenn du das durchgearbeitet hast kannst du wiederkommen.

[Shinja]

Also ich finde thordks Erklaerungen sehr hilfreich. Schoen seine Analyse des Problems beschrieben und wie man das dann eben umbaut. Sehr nett, danke dir!

Und ich glaube wenn man

So wie ich es jetzt verstanden habe, teilt man die probleme einer aufgabe in objekte auf... und die probleme teilt man dann in die methoden...
Oder sehe ich das falsch...

noch bisschen umformulieren wuerde kaeme doch was ganz verstaendliches dabei raus, oder nicht?

[Artchi]

Badestrand! Soweit fast richtig.

Hier wird ebend gerade nicht der Ctor aufgerufen:

Cl = new Cl; // Konstruktor

Hier schon:

Cl = new Cl(); // Konstruktor

[Gast]

Artchi schrieb:

Badestrand! Soweit fast richtig.

Hier wird ebend gerade nicht der Ctor aufgerufen:

Cl = new Cl; // Konstruktor

Interesante Theorie. Wenn Du jetzt noch erklären könntest wie ein neues Objekte der Klasse Cl hier konstruiert werden soll _ohne_ einen Ctor aufzurufen...

[wtf]

Artchi schrieb:

Badestrand! Soweit fast richtig.

Hier wird ebend gerade nicht der Ctor aufgerufen:

Cl = new Cl; // Konstruktor

Hier schon:

Cl = new Cl(); // Konstruktor

Artchi du enttäuscht mich zu tiefst!

[hustbaer]

Bei UDTs ist es vollkommen egal ob man "new UDT" oder "new UDT()" schreibt.
Der einzige Unterschied besteht bei eingebauten Typen, nämlich dass die zero-initialization weggelassen wird wenn man "new int" (ohne Klammern) schreibt. Was aber mit einem Konstruktor nixe nicht zu tun hat.

[camper]

schue schrieb:

Sqwan schrieb:

gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...

Zitat aus C++, die Programmiersprache, Seite 240 (KOnstruktoren): "Ein Konstruktor ist dadurch gekennzeichnet, daß er denselben Namen hat wie die zugehörige Klasse".

Manchmal hilft es wirklich die Standartwerke zu besitzen... Und sie auch zu lesen

Konstruktoren haben keine Namen (12.1/1). Es existiert lediglich eine spezielle Syntax, um sie - unter Verwendung des Klassennamens - zu deklarieren. Das gilt auch für Destruktoren. Der Standard macht sich hier gar nicht die Mühe, zu sagen, dass diese keine Namen haben; das folgt bereits aus ihrer Deklarationssyntax. ~T kann kein (gewöhnlicher) Name sein, denn es handelt sich lexikalisch um 2 Token.

hustbaer schrieb:

Bei UDTs ist es vollkommen egal ob man "new UDT" oder "new UDT()" schreibt.
Der einzige Unterschied besteht bei eingebauten Typen, nämlich dass die zero-initialization weggelassen wird wenn man "new int" (ohne Klammern) schreibt. Was aber mit einem Konstruktor nixe nicht zu tun hat.

Ob new T einen Konstruktor aufruft oder nicht hängt davon ab, ob T (bzw der Elementtyp, wenn T ein array ist) ein POD ist oder nicht. Zwar können (in deiesem Zusammenhang, wir ignorieren mal Referenzen) nur UDTs nicht-PODs sein, aber nicht jeder UDT ist nicht-POD.

[Gast]

camper schrieb:

schue schrieb:

Sqwan schrieb:

gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...

Zitat aus C++, die Programmiersprache, Seite 240 (KOnstruktoren): "Ein Konstruktor ist dadurch gekennzeichnet, daß er denselben Namen hat wie die zugehörige Klasse".

Manchmal hilft es wirklich die Standartwerke zu besitzen... Und sie auch zu lesen

Konstruktoren haben keine Namen (12.1/1). Es existiert lediglich eine spezielle Syntax, um sie - unter Verwendung des Klassennamens - zu deklarieren. Das gilt auch für Destruktoren. Der Standard macht sich hier gar nicht die Mühe, zu sagen, dass diese keine Namen haben; das folgt bereits aus ihrer Deklarationssyntax. ~T kann kein (gewöhnlicher) Name sein, denn es handelt sich lexikalisch um 2 Token.

Ok, dann schreib doch gleich Bjarne ne email das er das in seinem Buch falsch dargestellt hat.

[camper]

schue schrieb:

Ok, dann schreib doch gleich Bjarne ne email das er das in seinem Buch falsch dargestellt hat.

Erstmal schau ich mir das Ganze am WE (hab das Buch grad nicht zur Hand) im Original an, möglicherweise ist das Zitat auch unvollständig. Welches Kapitel ist das? Bei Widersprüchen hat der Text des Standards allerdings grundsätzlich Vorrang vor irgendwelchen externen Quellen, selbst wenn sie von Stroustrup stammen.

ISO/IEC 14882:2003 schrieb:

12.1 Constructors [class.ctor]
1 Constructors do not have names.

Da ist einfach kein Interpretationsspielraum.

[thordk]

wenn konstruktoren keinen namen haben, wie erklärt sich dann die implementierungssyntax Klasse::Klasse(){}? auch als spezielles schlagwort?

halte den auszug aus der ISO für daneben. klar haben konstruktoren einen namen, der sogar sehr wohl definiert ist.

[LordJaxom]

Tut mir leid, aber einen Namen (für den Ctor), der 100% mit dem der Klasse übereinstimmen muss, kann ich beim besten Willen nicht als eigenen Namen ansehen. Demnach würde ich doch eher der Aussage des Standards folgen, dass Konstruktoren keinen Namen haben...

Man könnte natürlich auch definieren dass ein Konstruktor als Namen den der Klasse hat (was ihn aber als "Eigennamen" im Sinne des Wortes disqualifiziert, weil er eben nicht frei definierbar ist). Was aber exakt aufs selbe hinausläuft.

Worum geht's hier eigentlich?

[Artchi]

wtf schrieb:

Artchi schrieb:

Badestrand! Soweit fast richtig.

Hier wird ebend gerade nicht der Ctor aufgerufen:

Cl = new Cl; // Konstruktor

Hier schon:

Cl = new Cl(); // Konstruktor

Artchi du enttäuscht mich zu tiefst!

Stell dir vor, ich bin auch nur ein Mensch!

[camper]

thordk schrieb:

wenn konstruktoren keinen namen haben, wie erklärt sich dann die implementierungssyntax Klasse::Klasse(){}? auch als spezielles schlagwort?

Das wurde bereits dargestellt, aberr bitte:

ISO/IEC 14882:2003 schrieb:

12.1 Constructors [class.ctor]
1 Constructors do not have names. A special declarator syntax using an optional sequence of functionspecifiers (7.1.2) followed by the constructor’s class name followed by a parameter list is used to declare or define the constructor.

Der Standard spricht grundsätzlich und konsistent nur vom "constructor's class name". Im Übrigen ist die Annahme eines Namens für Konstruktoren noch aus einem anderen Grunde irrig. Sie würde das name lookup aushebeln. Da der Name einer Klasse in ihren Namensraum "injiziert" wird (9/2 Satz 2) hätten wir dann plötzlich den Namen eines Typs als auch eine (möglicherweise überladene) Funktion gleichen Namens im selben Scope. Diese Möglichkeit ist in der Aufzählung von 3.3/4 aber nicht enthalten.

halte den auszug aus der ISO für daneben. klar haben konstruktoren einen namen, der sogar sehr wohl definiert ist.

Du darfst davon halten, was du willst. Was nun normativ ist oder nicht, wird von deiner Haltung nicht bestimmt.