Also ich habe eine komplex-Klasse geschrieben nur so aus lernzwecken und nun kann ich nicht Werte hinzufügen per:

dcomplex *neu = new dcomplex
neu(4,5);

es geht auch nicht:

dcomplex zahl(4,7); //OK!
zahl(4,6); //Fehler o_O

Wieso kann ich im letzten Beispiel damit initialisieren aber später keinen wert ändern?
Also da verstehe ich mal wieder etwas Grundsätzliches nicht.
Fehlermeldung:

error C2064: Ausdruck ergibt keine Funktion, die 2 Argumente übernimmt

Liegt das daran,weils nen Konstruktor ist und der nur beim Erzeugen des Objektes aufgerufen wird?
Wie muss ich das sonst denn aufrufen? Weil zahl.re(4) geht ja nicht wegen private. ausßerdem wäre es umständlich.

main.cpp

#include <iostream>
#include "dcomplex.h"

using namespace std;

int main(){
	getchar();
	dcomplex zahl1(4,5), zahl2(3,-2), zahl3(0,0), zahl4(4), zahl5;
	zahl1.disp(), zahl2.disp(), zahl3.disp(),zahl4.disp();
	getchar();
	dcomplex *neu = new dcomplex(4,5);  //Warum keine Initialisierung über z.B. neu(3,7);
	zahl5(8,5);
	zahl5.disp();
	neu->disp();
	getchar();
	delete neu;
	getchar();
	return 0;
}

dcomplex.h

class dcomplex{
private:
	double re,im;
public:
	dcomplex();
	~dcomplex();
	dcomplex(double x);
	dcomplex(double x,double y);
	void disp();
};

dcomplex.cpp

#include "dcomplex.h"
#include <iostream>

using namespace std;

dcomplex::dcomplex(){
	cout << "Objekt erzeugt.\n";
}
dcomplex::~dcomplex(){
	cout << "Objekt entfernt.\n";
}
dcomplex::dcomplex(double x){
	re = 0;
	im = x;
	cout << "Objekt erzeugt.\n";
}
dcomplex::dcomplex(double x, double y){
	re = x;
	im = y;
	cout << "Objekt erzeugt.\n";
}
void dcomplex::disp(){
	if(im >=0) cout << re << " + j" << im << endl;
	else cout << re << " - j" << -im << endl;
}

1).
Werte werden geändert indem du Get/set-funktionen oder sonstige funktionen der klasse aufrufst.

Beispiel:

void set_x(int xx)
{
    x = xx;
}

int get_x()
{
    return x;
}

2). benutze initialisierungsliste in Konstruktor

dcomplex::dcomplex(double x)
:re(0),im(x)
{
    cout << "Objekt erzeugt.\n";
}

2). Du solltest an deinem style arbeiten...

if(im >=0) cout << re << " + j" << im << endl;
    else cout << re << " - j" << -im << endl;

sieht einfach nur schrecklich aus, wenn du solchen code schreibst haben andere schwierigkeiten ihn zu verstehen

mein vorschlag:

if(im >= 0)
    cout << re << " + j" << im << endl;
else
    cout << re << " - j" << -im << endl

zahl1.disp(), zahl2.disp(), zahl3.disp(),zahl4.disp();

warum hast du kommas geschrieben, ich habe mich echt am anfang gefragt was das soll...
den komma operator für mehrere anweisungen solltest überhaupt nur, meiner meinung nach, in schleifen benutzen, ansonsten wird der code unübersichtlich.
ich versteh nicht waru es so schwer ein ; zu schreiben und eine neue reihe anzufangen

zahl1.disp(); 
zahl2.disp(); 
zahl3.disp();
zahl4.disp();

nein du kannst nicht den operator= dafür gebrauchen, da dann beide operanden DComplex instanzen sein müssen, du kannst aber eine funktion schreiben, die zwei parameter nimmt und dann einfuegt

ein konstruktor dient zum erstellen einer instanz einer klasse damit kannst du nachher nicht mehr die werte ändern!!!

1).
Werte werden geändert indem du Get/set-funktionen oder sonstige funktionen der klasse aufrufst.

Beispiel:

void set_x(int xx)
{
    x = xx;
}

int get_x()
{
    return x;
}

2). benutze initialisierungsliste in Konstruktor

dcomplex::dcomplex(double x)
:re(0),im(x)
{
    cout << "Objekt erzeugt.\n";
}

ja das hatte ich mir schon gedacht. naja okay wieder was gelernt.

uhsuhz schrieb:

2). Du solltest an deinem style arbeiten...

if(im >=0) cout << re << " + j" << im << endl;
    else cout << re << " - j" << -im << endl;

sieht einfach nur schrecklich aus, wenn du solchen code schreibst haben andere schwierigkeiten ihn zu verstehen

mein vorschlag:

if(im >= 0)
    cout << re << " + j" << im << endl;
else
    cout << re << " - j" << -im << endl

mhh naja so großartig anders ist dies nun auch nicht, ohne mich jetzt über deine zurecht geäußerte meinung beschweren zu wollen.
wie gesagt mir fehlt einfach die erfahrung, aber dennoch gebe ich mir mühe und es macht mir auch spaß etwas dazu zu lernen.

uhsuhz schrieb:

zahl1.disp(), zahl2.disp(), zahl3.disp(),zahl4.disp();

warum hast du kommas geschrieben, ich habe mich echt am anfang gefragt was das soll...
den komma operator für mehrere anweisungen solltest überhaupt nur, meiner meinung nach, in schleifen benutzen, ansonsten wird der code unübersichtlich.
ich versteh nicht waru es so schwer ein ; zu schreiben und eine neue reihe anzufangen

zahl1.disp(); 
zahl2.disp(); 
zahl3.disp();
zahl4.disp();

wo ist da denn eigentlich der unterschied? ich finde das mit dem, nen bisschen übersichtlicher. kannst du mir den genaueren grund erläutern oder ist das einfach nur eine frage des übersichtlichen aufbaus?

danke timo

naja einen unterschied im resultat gibt es keinen, nur könnte man beim überfliegen des codes mal was verwechseln, was mir geschehen ist.

Ich finde dei Mehrzeilervariante auch viel lesbarer. Ich sehe da gerade, dass auf 4 Objekte des gleichen Typs die gleiche Funktion aufgerufen wird. Ich muss da praktisch nix lesen. Meine Augen erkennen das als ganzes. In einer Linie muss ich alles lesen, damit ich verstehe, was du machst.

Das ganze kann mit Speedreading erklärt werden. Es ist ja so, dass unser Hirn vertikale Anordnungen auch sehr viel schneller aufnehmen kann, als lange Horizontale Zeilen. Ist mitunter ein Grund, warum Zeitungen diese Gliederung haben, dass nur sehr wenig auf eine Zeile kommt und dann auf die nächste Zeile gesprungen wird.
Vor allem bei Programmierern wird das Vertikale Lesevermögen noch viel besser trainiert sein, als die Horizontale.

btw:
Speedreading: Ein sehr interessantes Thema und kann im Studium sicher noch viel helfen. Man braucht viel Übung, aber man merkt die Fortschritte schon, wenn man viel liest. (Wer tut das im Studium nicht. )

Soo ich habe dann mal ein wenig weiter gearbeitet und laut Aufgabenstellung alles zusammen gebastelt. Es funktioniert sogar ^^
Meckert einfach mal los, wenn euch was nicht gefällt.
Es ist nur ein wenig durch die Aufgabenstellung durcheinander, sonst hätt ich es wohl einheitlicher gemacht.
Was mir nur nicht gefällt ist dieses doppelt und dreifache includieren und "using namespace std;", nur wenn ich es weglasse bekomme ich Fehler.

dcomplex.h

#include <iostream>
using namespace std;

class dcomplex{
private:
	double re,im;
public:
	//Konstruktoren & Destruktor
	dcomplex();
	~dcomplex();
	dcomplex(double);
	dcomplex(double,double);

	//Ueberladene Operatoren
	dcomplex operator + (dcomplex);
	dcomplex operator * (dcomplex);
	friend ostream& operator << (ostream &os, const dcomplex &c);
	friend istream& operator >> (istream &is, dcomplex &c);

	//Komponentenfunktionen
	void disp();
	void set(double,double);
	double r();
	double i();
	double betrag();
	double winkel();
	dcomplex konj();
	dcomplex kehr();

};

dcomplex.cpp

#include "dcomplex.h"
#include <iostream>
#include <cmath>

using namespace std;

//Konstruktoren & Destruktor
dcomplex::dcomplex(){
	cout << "\nObjekt erzeugt.\n";
}
dcomplex::~dcomplex(){
	cout << "\nObjekt entfernt.\n";
}
dcomplex::dcomplex(double x){
	re = 0;
	im = x;
	cout << "\nObjekt erzeugt.\n";
}
dcomplex::dcomplex(double x, double y){
	re = x;
	im = y;
	cout << "\nObjekt erzeugt.\n";
}

//Ueberladene Operatoren
dcomplex dcomplex::operator + (dcomplex c){
	return dcomplex(re + c.re, im + c.im);
}
dcomplex dcomplex::operator * (dcomplex c){
	return dcomplex(re*c.re - im*c.im, re*c.im + im*c.re);
}
ostream& operator << (ostream &os, const dcomplex &c){
	if(c.im >=0)
		os << c.re << " + j" << c.im << endl;
	else
		os << c.re << " - j" << -c.im << endl;
	return os;
}
istream& operator >> (istream &is, dcomplex &c){
	char z;
	is >> c.re >> z >> c.im;
	return is;
}

//Komponentenfunktionen
void dcomplex::disp(){
	if(im >=0)
		cout << re << " + j" << im;
	else
		cout << re << " - j" << -im;
}
void dcomplex::set(double x, double y){
	re = x;
	im = y;
}
double dcomplex::r(){ return re; }
double dcomplex::i(){ return im; }
double dcomplex::betrag(){
	return sqrt(re*re+im*im);
}
double dcomplex::winkel(){
	return atan(im/re);
}
dcomplex dcomplex::konj(){
	return dcomplex(re,-im);
}
dcomplex dcomplex::kehr(){
	dcomplex c;
	c.re = re/(re*re-im*im);
	c.im = -im/(re*re-im*im);
	return c;
}

main.cpp

#include <iostream>
#include "dcomplex.h"

using namespace std;

int main(){
	cout << "Eigene Klasse - dcomplex\n\n";
	dcomplex a;
	dcomplex b;
	dcomplex c;
	cout << "Bitte geben Sie Werte fuer Variable a ein (Format: \"re,im\"): ";
	cin >> a;
	cout << "Bitte geben Sie Werte fuer Variable b ein (Format: \"re,im\"): ";
	cin >> b;
	cout << "Ausgabe von a: " << a;
	cout << "Ausgabe von b: ";
	b.disp();
	cout << "\nBetrag von a: " << a.betrag();
	cout << "\nWinkel von b: " << b.winkel();
	cout << "\nDas konjugiert Komplexe von a: "
		 << a.konj();
	cout << "\nKehrwert von b: "
		 << b.kehr();
	cout << "\nAddition von a und b, speichern in c: ";
	c = a + b;
	cout << c;
	cout << "\nMultiplikation von a und b, speichern in c: ";
	c = a * b;
	cout << c;
	cin.get();
	cin.get();
}

Was mich nur ein wenig wundert sind die Ausgabe von den Konstruktoren und des Destruktors.
Es wurden laut meinem Programm (da haben wir schon den Fehler ^^) mehr Komponenten entfernt als hinzugefügt.

Eigene Klasse - dcomplex

Objekt erzeugt.

Objekt erzeugt.

Objekt erzeugt.
Bitte geben Sie Werte fuer Variable a ein (Format: "re,im"): 1.1,2.2
Bitte geben Sie Werte fuer Variable b ein (Format: "re,im"): 3.3,4.4
Ausgabe von a: 1.1 + j2.2
Ausgabe von b: 3.3 + j4.4
Betrag von a: 2.45967
Winkel von b: 0.927295
Objekt erzeugt.

Das konjugiert Komplexe von a: 1.1 - j2.2

Objekt entfernt.

Objekt erzeugt.

Objekt entfernt.

Kehrwert von b: -0.38961 + j0.519481

Objekt entfernt.

Addition von a und b, speichern in c:
Objekt erzeugt.

Objekt entfernt.

Objekt entfernt.
4.4 + j6.6

Multiplikation von a und b, speichern in c:
Objekt erzeugt.

Objekt entfernt.

Objekt entfernt.
-6.05 + j12.1

Objekt entfernt.

Objekt entfernt.

Objekt entfernt.

Danke für eure Antworten und vorallem eure Zeit!

Dann könntest du noch die + und - Operatoren eher ausserhalb der Klasse deklarieren/definieren. Die gehören ja nicht direkt zu einem Objekt.

Das using namespace schreibe NIEMALS in einen Header. Der Header wird sehr wahrscheinlich von jemanden included und dann hat der einen Haufen Namenskonflikte und weiss nicht woher.

Du kannst dafür den Auflösungsoperator :: benutzen. Also z.B so:

std::ostream

Was die Logging-Ausgaben betrifft: Notfalls kannst du sie auch in der Klasse belassen und bedingt kompilieren. Wenn ein bestimmtes Makro definiert wurde, werden Ausgaben getätigt, sonst nicht. Das ist sehr praktisch für Debug-Ausgaben und wird normalerweise problemlos weggelassen.

#ifdef DCOMPLEX_LOG
std::cout << "Objekt erzeugt." << std::endl;
#endif

In der Hauptdatei könnte z.B. stehen:

#define DCOMPLEX_LOG
#include "dcomplex.h"

Das einzige Problem ist vielleicht der Platz (3 Zeilen für eine Ausgabe). Das könnte man mit einem weiteren Makro lösen ;):

#ifdef DCOMPLEX_LOG
 #define LOG_OUTPUT(a) std::cout << a << std::endl // Logging-Ausgabe
#else
 #define LOG_OUTPUT(a) (void)0    // ansonsten macht das Makro nichts
#endif

Angewandt:

LOG_OUTPUT("Objekt erzeugt.");

Wie du siehst, sind solche Makros ziemlich praktisch. Sieh jedoch davon ab, sie zu häufig zu verwenden, sie haben nämlich beträchtliche Nachteile. Aber für Debug-Loggingausgaben sind sie meiner Ansicht nach durchaus legitim.

Wie du siehst, sind solche Makros ziemlich praktisch. Sieh jedoch davon ab, sie zu häufig zu verwenden, sie haben nämlich beträchtliche Nachteile. Aber für Debug-Loggingausgaben sind sie meiner Ansicht nach durchaus legitim.

Phu..
Ich würde da eher, wenn schon eine statische Logger Klasse schreiben, wo man den outputstream angeben kann. Dort kann man die Ausgabemenge auch noch mit Makros steuern, wenn man mag. Aber so direkt mit Makros rumfrickeln, würde ich abraten.

Mal abgesehen von Tracing ist das aber ja eigentlich nicht nötig und gehört ansonsten auch nicht in die Klasse.

Jedoch verstehe ich nicht warum häufiger ein Objekt der Klasse vernichtet als erzeugt wird. Das is doch unlogisch.

Du hast Kopierkonstruktor-Aufrufe auch nicht ins Logging miteinbezogen.

dcomplex(const dcomplex &c){
cout << "Objekt erzeugt.\n";}

reicht das dann? oder muss ich im kopierkonstruktor noch definieren wie er zu kopieren hat?
Muss eigentlich das c noch mit rein? (von dcomplex(const dcomplex &c){..)

Deklaration in der Klasse:

dcomplex(const dcomplex& other); // oder
dcomplex(const dcomplex&); // würde ich aber generell nicht empfehlen

Definition ausserhalb:

dcomplex::dcomplex(const dcomplex& other)
: re(other.re)
, im(other.im)
{
   std::cout << "Objekt erzeugt.\n";
}

Gewöhn dir am besten gleich an, immer std:: vor die Bezeichner der Standardbibliothek zu schreiben, dann kriegst du damit keine Probleme.

EDIT:

Genau so wie du bei der Definition einen Bezeichner für den Parameter angeben musst (wie in jeder Funktion).

Nö, nur wenn man den/die Parameter auch verwenden will:

int Func(boost::type<int>)
{
    return 1;
}
double Func(boost::type<double>)
{
    return 0.1;
}

dcomplex::dcomplex(double x){
    re = 0;
    im = x; // <-- WTF???
    cout << "\nObjekt erzeugt.\n";
}

was stimmt daran nicht?

ntfs2008 schrieb:

hustbaer schrieb:

dcomplex::dcomplex(double x){
    re = 0;
    im = x; // <-- WTF???
    cout << "\nObjekt erzeugt.\n";
}

was stimmt daran nicht?

passt schon...

MfG,

Probe-Nutzer

Hallo,

ntfs2008 schrieb:

hustbaer schrieb:

dcomplex::dcomplex(double x){
    re = 0;
    im = x; // <-- WTF???
    cout << "\nObjekt erzeugt.\n";
}

was stimmt daran nicht?

passt schon...

Nö! Woher soll der Anwender denn wissen, dass er den imaginärteil angibt, wenn er nur ein Parameter angibt? Dann mach wenigstens

dcomplex::dcomplex (const double &_im)
: re (0), im (_im)
{}

Wobei ich diesen CTor einfach weglassen würde...

Übrigens würde ich davon abraten, die Variablenbez. in Headern wegzulassen, nur weil man nicht gezwungen wird, sie da hinzuschreiben... Im Header kann man viel schneller nachsehen, was für Variablen erwartet werden...

bb

hustbaer schrieb:

Genau so wie du bei der Definition einen Bezeichner für den Parameter angeben musst (wie in jeder Funktion).

Nö, nur wenn man den/die Parameter auch verwenden will

Danke für die Berichtigung. Aber es wird sowieso in 99% der Fälle so sein, dass man die Argumente innerhalb der Funktion benötigt.

Probe-Nutzer schrieb:

Hallo,

ntfs2008 schrieb:

hustbaer schrieb:

dcomplex::dcomplex(double x){
    re = 0;
    im = x; // <-- WTF???
    cout << "\nObjekt erzeugt.\n";
}

was stimmt daran nicht?

passt schon...

Nö! Woher soll der Anwender denn wissen, dass er den imaginärteil angibt, wenn er nur ein Parameter angibt?

Hi also wenn man nur eine Zahl angibt dann ist es doch wohl klar das dies nur der imaginäre Teil ist. Wenns andersrum wäre dann bräuchte ich doch wohl kaum komplexe Zahlen. Es würden dann ja einfache reelle reichen.

[quote="unskilled"]

Probe-Nutzer schrieb:

Dann mach wenigstens

dcomplex::dcomplex (const double &_im)
: re (0), im (_im)
{}

Wobei ich diesen CTor einfach weglassen würde...

Was macht der obrige Code? Da kann ich absolut nichts mit anfangen.
Zudem: Was ist ein CTOR? Konstruktor oder wie?

[quote="unskilled"]

Probe-Nutzer schrieb:

Übrigens würde ich davon abraten, die Variablenbez. in Headern wegzulassen, nur weil man nicht gezwungen wird, sie da hinzuschreiben... Im Header kann man viel schneller nachsehen, was für Variablen erwartet werden...

bb

Klingt absolut logisch! Wird ab jetzt beherzigt! Danke
Gruß Timo

...
Hi also wenn man nur eine Zahl angibt dann ist es doch wohl klar das dies nur der imaginäre Teil ist....

Also mir begegnet dieser Schluss zum ersten Mal.
Da habe ich sogar den gegenteiligen Schluss ("Wenn nur ein Argument, dann ist doch klar, dass es nur der Realteil ist!") sowohl öfter begegnet als auch ein wenig schlüssiger (was nicht bedeuten soll, dass ich das so machen würde!).

Was würdest Du denn erwarten bei:

double real = 1.2;
   dcomplex compl;

   compl = real;

Würdest Du da auch erwarten, dass compl rein imaginär wäre ?
OK, den operator=(double) musst Du nicht (so) implementieren, aber semantisch ist er seeeehr nah am Ctor(double), z.B: in:

void do_with_complex(dcomplex d);

int main() {
   double real = 1.2;
   do_with_complex(real);
...

unskilled schrieb:

Probe-Nutzer schrieb:

Hallo,

ntfs2008 schrieb:

hustbaer schrieb:

dcomplex::dcomplex(double x){
    re = 0;
    im = x; // <-- WTF???
    cout << "\nObjekt erzeugt.\n";
}

was stimmt daran nicht?

passt schon...

Nö! Woher soll der Anwender denn wissen, dass er den imaginärteil angibt, wenn er nur ein Parameter angibt? ...

sowas macht z.B. folgendermaßen Probleme:

dcomplex a1(1,2), a2(3.4), a3(5,6);

Na ? War das wirklich das, was der Programmierer wollte ?
Insgesamt muss man sehr vorsichtig sein mit solchen "Konvertierungstoren" (Ctor wenigstens "explicit" machen)...

Gruß,

Simon2.

dcomplex::dcomplex(double real = 0, double imag = 0)
: re(real)
, im(imag)
{
}

Dann hat man auch gleich für einen Default-Ctor gesorgt. Den Zuweisungsoperator müsste man in diesem Fall angleichen, um die gleiche Semantik für 1 Argument zu erzielen.

Es ist wohl naheliegender, den Realteil zu spezifizieren, wenn man nur ein Argument übergibt.

dcomplex c = 4; // rechts steht der Wert 4, wieso sollte
                // links danach nicht auch den selben Wert haben?

Oder, um ganz sicher zu sein, kann man es wie Simon2 machen: Konstruktor explizit und ohne Defaultparameter (man muss so auch ausdrücklich angeben, dass der Imaginärteil 0 ist, wenn man eine rein reelle komplexe Zahl will).

...
Es ist wohl naheliegender, den Realteil zu spezifizieren, wenn man nur ein Argument übergibt...

@ntfs: siehste ? :p

Gruß,

Simon2.

Nö! Woher soll der Anwender denn wissen, dass er den imaginärteil angibt, wenn er nur ein Parameter angibt?

Und woher soll ntfs2008 wissen, dass das gemeint ist?

ntfs2008 hatte eventuell andere Bedenken, als er sich wunderte, warum der Kommentar da steht.

Da, wo der Kommentar steht, gilt also "passt schon", nichts anderes war gemeint, wenn auch noch mehr dazu zu sagen gewesen wäre:

Passendere Anmerkung wäre also gewesen: warum nur ein solcher Konstruktor, warum dann nicht auch einer, der nur den Realteil initialisiert, warum überhaupt dieser Konstruktor, oder...

Ich dachte mir auch, dass dies der Grund ist, aber dann bitte doch explizit und nicht implizit, so hilft das auch nicht so versierten Leuten.

MfG,

Probe-Nutzer